http://www.tkk7.com/jinfeng_wang/archive/2005/04/01/2706.html
package com.oreilly.hh;
import net.sf.hibernate.*;
import net.sf.hibernate.cfg.Configuration;
import java.sql.Time;
import java.util.Date;
/**//**
* Create sample data, letting Hibernate persist it for us.
*/
public class CreateTest 
{
public static void main(String args[]) throws Exception {
// Create a configuration based on the properties file we've put
// in the standard place.
Configuration config = new Configuration();
// Tell it about the classes we want mapped, taking advantage of
// the way we've named their mapping documents.
config.addClass(Track.class);
// Get the session factory we can use for persistence
SessionFactory sessionFactory = config.buildSessionFactory();
// Ask for a session using the JDBC information we've configured
Session session = sessionFactory.openSession();
Transaction tx = null;
try {
// Create some data and persist it
tx = session.beginTransaction();
Track track = new Track("Russian Trance",
"vol2/album610/track02.mp3",
Time.valueOf("00:03:30"), new Date(),
(short)0);
session.save(track);
track = new Track("Video Killed the Radio Star",
"vol2/album611/track12.mp3",
Time.valueOf("00:03:49"), new Date(),
(short)0);
session.save(track);
track = new Track("Gravity's Angel",
"vol2/album175/track03.mp3",
Time.valueOf("00:06:06"), new Date(),
(short)0);
session.save(track);
// We're done; make our changes permanent
tx.commit();
} catch (Exception e) {
if (tx != null) {
// Something went wrong; discard all partial changes
tx.rollback();
}
throw e;
} finally {
// No matter what, close the session
session.close();
}
// Clean up after ourselves
sessionFactory.close();
}
}
When it comes time to actually perform persistence, we ask the SessionFactory to open a Session for us (line 27), which establishes a JDBC connection to the database, and provides us with a context in which we can create, obtain, manipulate, and delete persistent objects. As long as the session is open, a connection to the database is maintained, and changes to the persistent objects associated with the session are tracked so they can be applied to the database when the session is closed. Conceptually you can think of a session as a 'large scale transaction' between the persistent objects and the database, which may encompass several database-level transactions. Like a database transaction, though, you should not think about keeping your Hibernate session open over long periods of application existence (such as while you're waiting for user input). A single session is used for a specific and bounded operation in the application, something like populating the user interface or making a change that has been committed by the user. The next operation will use a new session. Also note that Session objects are not thread safe, so they cannot be shared between threads. Each thread needs to obtain its own session from the factory.
現在開始講述“持久化操作”。在第27行，使用SessionFactory打開了Session，建立了數據庫JDBC的連接，（該連接已經進行了初始化），我們可以借用它進行一系列的操作，例如：創建、獲取、操縱、刪除持久化對象。只要session處于open狀態，那么對數據庫的連接就一直建立著，所有對已經和session綁定的持久化對象的操作都會被記錄下來，并且在session關閉的時候，所有的這些操作就會被更新到數據庫中。從概念上理解，你可以將session看作一個在持久化對象和數據庫之間的“大規模的事務”，它可以跨越幾個數據庫事務。正如數據庫事務那樣，你不該在程序中將hibernate session長時間的打開著（例如當程序在等待用戶輸入的時候），程序中的每個單獨的操作都該采用單獨的session，例如在“彈出用戶界面，或者將用戶的修改提交到數據庫”中，就該使用兩個session。同樣需要注意的是，session是線程不安全的，因此無法在線程之間共享session，每個線程都應該使用SessionFactory建立自己的sess。
We need to look more closely at the lifecycle of mapped objects in Hibernate, and how this relates to sessions, because the terminology is rather specific and the concepts are quite important. A mapped object such as an instance of our Track class moves back and forth between two states with respect to Hibernate: transient and persistent. An object that is transient is not associated with any session. When you first create a Track instance using new(), it is transient; unless you tell Hibernate to persist it, the object will vanish when it is garbage collected or your application terminates.
下面我們對hibernate中被映射對象的聲明周期進行說明，因為被映射對象相關的術語是相當特別的、它的概念也是很重要的。在hibernate中，被映射對象（例如程序中的Track對象）會在兩個狀態中不斷的來回切換：臨時（transient）狀態和持久（persistent）狀態。未曾與session綁定的對象就處于臨時狀態，例如程序中剛開始new出來的Track對象，它就處于臨時狀態。除非你通知hibernate對它進行持久化，否則整個對象就會在垃圾收集器回收或者程序結束的時候消逝。
Passing a transient mapped object to a Session's save() method causes it to become persistent. It will survive garbage collection and termination of the Java VM, staying available until it is explicitly deleted. (There is a related distinction between entities and values discussed at the beginning of Appendix A. Mapped objects that have been persisted are called entities, even if they do not currently exist as an instance in any virtual machine.) If you've got a persistent object and you call Session's delete() method on it, the object transitions back to a transient state. The object still exists as an instance in your application, but it is no longer going to stay around unless you change your mind and save it again; it's ceased being an entity.
但是，將一個臨時對象使用session的save方法保存之后，它就處于持久狀態，即使在垃圾回事或者Java VM結束之后，它都一直存在，知道該對象被明確刪除為止（在附錄A開頭有相關“entities和values區別”的討論，即使其在虛擬機中并不真實存在著一個對象與之相對應）。當你對持久化對象調用session.delete()方法時，該對象又變為臨時狀態。雖然該對象仍然在程序中做為一個實例存在著，但是除非你改變主意再次將其持久化，那么它將很快的消逝，它的“實體(entity)”也就愕然而之。
On the other hand, and this point is worth extra emphasis, if you haven't deleted an object (so it's still persistent), when you change its properties there is no need to save it again for those changes to be reflected in the database. Hibernate automatically tracks changes to any persistent objects and flushes those changes to the database at appropriate times. When you close the session, any pending changes are flushed.
另一方面，需要強調的是：如若你不刪除某持久化對象，那么當你改變其屬性時，并不需要顯示的對其的改變進行保存。hibernate將會自動的跟蹤到你對持久化對象的改變，然后在適當的時候將這些改變填入到數據庫中。
An important but subtle point concerns the status of persistent objects you worked with in a session that has been closed, such as after you run a query to find all entities matching some criteria (you'll see how to do this in the upcoming section, 'Finding Persistent Objects'). As noted above, you don't want to keep this session around longer than necessary to perform the database operation, so you close it once your queries are finished. What's the deal with the mapped objects you've loaded at this point? Well, they were persistent while the session was around, but once they are no longer associated with an active session (in this case because the session has been closed) they are not persistent any longer. Now, this doesn't mean that they no longer exist in the database; indeed, if you run the query again (assuming nobody has changed the data in the meantime), you'll get back the same set of objects; they're still entities. It simply means that there is not currently an active correspondence being maintained between the state of the objects in your virtual machine and the database. It is perfectly reasonable to carry on working with the objects. If you later need to make changes to the objects and you want the changes to 'stick,' you will open a new session and use it to save the changed objects. Because each entity has a unique ID, Hibernate has no problem figuring out how to link the transient objects back to the appropriate persistent state in the new session.
下面討論“在session關閉后，和session綁定的持久化對象的狀態”的問題。例如當你執行了一個查詢，得到了你所需要的實體對象之后，正如前面所述的那樣，你不應該將session保持過久，使之超出數據庫操作的范圍，這時候你將會關閉session。那么此時那些已經載入的映射對象處于什么狀態呢？答案是這樣的，在session的打開的過程中，它是處于持久化狀態，但是它一旦不在和active session（因為此時session已經關閉）綁定，那么它就處于持久化狀態。但是，這并不意味著他們在數據庫中就不再存在，事實上，如果你再次執行查詢（假設此間無人修改數據），那么你將可以得到同樣的集合數據。也就是說，虛擬機中的對象所處的狀態和數據庫中的實體數據的狀態之間并沒有必然的聯系。這時候，你可以對那些對象進行自己的操作，如果你改變了一些對象的數據，并想將其存儲到數據庫中，那么你必須重新建立一個session，使用它保存那些經過改變的數據。因為每個實體都有自己的唯一ID，因此hibernate可以很容易的在新的session中計算出如何將臨時對象重新轉換為相應的持久對象。
Armed with these concepts and terms, the remainder of the example is easy enough to understand. Line 31 sets up a database transaction using our open session. Within that, we create a few Track instances containing sample data and save them in the session (lines 33-50), turning them from transient instances into persistent entities. Finally, line 53 commits our transaction, atomically (as a single, indivisible unit) making all the database changes permanent. The try/catch/finally block wrapped around all this shows an important and useful idiom for working with transactions. If anything goes wrong, lines 56-60 will roll back the transaction and then bubble out the exception, leaving the database the way we found it. The session is closed in the finally portion at line 63, ensuring that this takes place whether we exit through the 'happy path' of a successful commit, or via an exception that caused rollback. Either way, it gets closed as it should.
通過上面的概念的講述和討論，那么例子中的其他部分也就很好理解了。第31行，使用打開的session建立了數據庫事務。在事務中，33－50行創建了一個Track對象，并在session中將其保存，將其從臨時對象變為持久對象。最后，53行提交事務，原子性的執行數據庫改變。這里的try/catch/finally封裝了事務處理中常出現的idom。一旦出現任何問題，56－60行就會回滾事務，然后拋出異常，保證數據庫維持原狀。無論如何，都會執行finnally塊中的63行，無論在成功執行或者出現錯誤回滾的情況下，都會關閉session。
At the end of our method we also close the session factory itself on line 67. This is something you'd do in the 'graceful shutdown' section of your application. In a web application environment, it would be in the appropriate lifecycle event handler. In this simple example, when the main() method returns, the application is ending.
在方法的最后67行，將會關閉session factory。這是你的應用程序正常退出時應該執行的操作。在Web程序中，你則需要使用一定的生命周期事件處理器，完成此操作。在我們的例子中，在main退出的時候，也就是程序中止的時間。