Java Persistence with Hibernate phần 7 pdf

Conversations with Hibernate 489 the user (“Sorry, somebody modified the same auction!”) and force a restart of the conversation from step one. How can you make the conversation atomic? The conversation spans several persistence contexts and several database transactions. But this isn’t the scope of a unit of work from the point of view of the application user; she considers the con- versation to be an atomic group of operations that either all fail or all succeed. In the current conversation this isn’t a problem, because you modify and persist data only in the last (second) step. Any conversation that only reads data and delays all reattachment of modified objects until the last step is automatically atomic and can be aborted at any time. If a conversation reattaches and commits modifica- tions to the database in an intermediate step, it’s no longer atomic. One solution is to not flush the persistence contexts on commit—that is, to set a FlushMode.MANUAL on a Session that isn’t supposed to persist modifications (of course, not for the last step of the conversation). Another option is to use compen- sation actions that undo any step that made permanent changes, and to call the appropriate compensation actions when the user aborts the conversation. We won’t have much to say about writing compensation actions; they depend on the conversation you’re implementing. Next, you implement the same conversation with a different strategy, eliminat- ing the detached object state. You extend the persistence context to span the whole conversation. 11.2.3 Extending a Session for a conversation The Hibernate Session has an internal persistence context. You can implement a conversation that doesn’t involve detached objects by extending the persistence context to span the whole conversation. This is known as the session-per-conversation strategy, as shown in figure 11.3. A new Session and persistence context are opened at the beginning of a con- versation. The first step, loading of the Item object, is implemented in a first data- base transaction. The Session is automatically disconnected from the underlying JDBC Connection as soon as you commit the database transaction. You can now hold on to this disconnected Session and its internal persistence context during user think-time. As soon as the user continues in the conversation and executes the next step, you reconnect the Session to a fresh JDBC Connection by begin- ning a second database transaction. Any object that has been loaded in this con- versation is in persistent state: It’s never detached. Hence, all modifications you made to any persistent object are flushed to the database as soon as you call flush() on the Session . You have to disable automatic flushing of the Session by 490 CHAPTER 11 Implementing conversations setting a FlushMode.MANUAL —you should do this when the conversation begins and the Session is opened. Modifications made in concurrent conversations are isolated, thanks to opti- mistic locking and Hibernate’s automatic version-checking during flushing. Atom- icity of the conversation is guaranteed if you don’t flush the Session until the last step, the end of the conversation—if you close the unflushed Session , you effec- tively abort the conversation. We need to elaborate on one exception to this behavior: the time of insertion of new entity instances. Note that this isn’t a problem in this example, but it’s something you’ll have to deal with in more complex conversations. Delaying insertion until flush-time To understand the problem, think about the way objects are saved and how their identifier value is assigned. Because you don’t save any new objects in the Com- plete Auction conversation, you haven’t seen this issue. But any conversation in which you save objects in an intermediate step may not be atomic. The save() method on the Session requires that the new database identifier of the saved instance must be returned. So, the identifier value has to be gener- ated when the save() method is called. This is no problem with most identifier generator strategies; for example, Hibernate can call a sequence , do the in-mem- ory increment , or ask the hilo generator for a new value. Hibernate doesn’t have load manual flush Figure 11.3 A disconnected persistence context extended to span a conversation Conversations with Hibernate 491 to execute an SQL INSERT to return the identifier value on save() and assign it to the now-persistent instance. The exceptions are identifier-generation strategies that are triggered after the INSERT occurs. One of them is identity , the other is select ; both require that a row is inserted first. If you map a persistent class with these identifier generators, an immediate INSERT is executed when you call save() ! Because you’re committing database transactions during the conversation, this insertion may have permanent effects. Look at the following slightly different conversation code that demonstrates this effect: Session session = getSessionFactory().openSession(); session.setFlushMode(FlushMode.MANUAL); // First step in the conversation session.beginTransaction(); Item item = (Item) session.get(Item.class, new Long(123) ); session.getTransaction().commit(); // Second step in the conversation session.beginTransaction(); Item newItem = new Item(); Long newId = (Long) session.save(newItem); // Triggers INSERT! session.getTransaction().commit(); // Roll back the conversation! session.close(); You may expect that the whole conversation, the two steps, can be rolled back by closing the unflushed persistence context. The insertion of the newItem is sup- posed to be delayed until you call flush() on the Session , which never happens in this code. This is the case only if you don’t pick identity or select as your identifier generator. With these generators, an INSERT must be executed in the second step of the conversation, and the INSERT is committed to the database. One solution uses compensation actions that you execute to undo any possible insertions made during a conversation that is aborted, in addition to closing the unflushed persistence context. You’d have to manually delete the row that was inserted. Another solution is a different identifier generator, such as a sequence , that supports generation of new identifier values without insertion. The persist() operation exposes you to the same problem. However, it also provides an alternative (and better) solution. It can delay insertions, even with post-insert identifier generation, if you call it outside of a transaction: 492 CHAPTER 11 Implementing conversations Session session = getSessionFactory().openSession(); session.setFlushMode(FlushMode.MANUAL); // First step in the conversation session.beginTransaction(); Item item = (Item) session.get(Item.class, new Long(1)); session.getTransaction().commit(); // Second step in the conversation Item newItem = new Item(); session.persist(newItem); // Roll back the conversation! session.close(); The persist() method can delay inserts because it doesn’t have to return an identifier value. Note that the newItem entity is in persistent state after you call persist() , but it has no identifier value assigned if you map the persistent class with an identity or select generator strategy. The identifier value is assigned to the instance when the INSERT occurs, at flush-time. No SQL statement is executed when you call persist() outside of a transaction. The newItem object has only been queued for insertion. Keep in mind that the problem we’ve discussed depends on the selected iden- tifier generator strategy—you may not run into it, or you may be able to avoid it. The nontransactional behavior of persist() will be important again later in this chapter, when you write conversations with JPA and not Hibernate interfaces. Let’s first complete the implementation of a conversation with an extended Session . With a session-per-conversation strategy, you no longer have to detach and reattach (or merge) objects manually in your code. You must implement infrastructure code that can reuse the same Session for a whole conversation. Managing the current Session The current Session support we discussed earlier is a switchable mechanism. You’ve already seen two possible internal strategies: One was thread-bound, and the other bound the current Session to the JTA transaction. Both, however, closed the Session at the end of the transaction. You need a different scope of the Session for the session-per-conversation pattern, but you still want to be able to access the current Session in your application code. A third built-in option does exactly what you want for the session-per-conversa- tion strategy. You have to enable it by setting the hibernate.current_session_ context_class configuration option to managed . The other built-in options we’ve discussed are thread and jta , the latter being enabled implicitly if you configure Hibernate for JTA deployment. Note that all these built-in options are implemen- tations of the org.hibernate.context.CurrentSessionContext interface; you Conversations with Hibernate 493 could write your own implementation and name the class in the configuration. This usually isn’t necessary, because the built-in options cover most cases. The Hibernate built-in implementation you just enabled is called managed because it delegates the responsibility for managing the scope, the start and end of the current Session , to you. You manage the scope of the Session with three static methods: public class ManagedSessionContext implements CurrentSessionContext { public static Session bind(Session session) { } public static Session unbind(SessionFactory factory) { } public static boolean hasBind(SessionFactory factory) { } } You can probably already guess what the implementation of a session-per-conver- sation strategy has to do: ■ When a conversation starts, a new Session must be opened and bound with ManagedSessionContext.bind() to serve the first request in the conversa- tion. You also have to set FlushMode.MANUAL on that new Session , because you don’t want any persistence context synchronization to occur behind your back. ■ All data-access code that now calls sessionFactory.getCurrentSession() receives the Session you bound. ■ When a request in the conversation completes, you need to call Managed- SessionContext.unbind() and store the now disconnected Session some- where until the next request in the conversation is made. Or, if this was the last request in the conversation, you need to flush and close the Session . All these steps can be implemented in an interceptor. Creating a conversation interceptor You need an interceptor that is triggered automatically for each request event in a conversation. If you use EJBs, as you’ll do soon, you get much of this infrastructure code for free. If you write a non- Java EE application, you have to write your own interceptor. There are many ways how to do this; we show you an abstract inter- ceptor that only demonstrates the concept. You can find working and tested inter- ceptor implementations for web applications in the CaveatEmptor download in the org.hibernate.ce.auction.web.filter package. Let’s assume that the interceptor runs whenever an event in a conversation has to be processed. We also assume that each event must go through a front door controller and its execute() action method—the easiest scenario. You can now wrap an interceptor around this method; that is, you write an interceptor that is 494 CHAPTER 11 Implementing conversations called before and after this method executes. This is shown in figure 11.4; read the numbered items from left to right. When the first request in a conversation hits the server, the interceptor runs and opens a new Session B; automatic flushing of this Session is immediately disabled. This Session is then bound into Hibernate’s ManagedSessionContext . A transaction is started C before the interceptor lets the controller handle the event. All code that runs inside this controller (or any DAO called by the control- ler) can now call sessionFactory.getCurrentSession() and work with the Ses- sion . When the controller finishes its work, the interceptor runs again and unbinds the current Session D. After the transaction is committed E, the Ses- sion is disconnected automatically and can be stored during user think-time. Now the server waits for the second request in the conversation. As soon as the second request hits the server, the interceptor runs, detects that there is a disconnected stored Session , and binds it into the ManagedSession- Context F. The controller handles the event after a transaction was started by the interceptor G. When the controller finishes its work, the interceptor runs again and unbinds the current Session from Hibernate. However, instead of discon- necting and storing it, the interceptor now detects that this is the end of the conversation and that the Session needs to be flushed H, before the transaction is committed I. Finally, the conversation is complete and the interceptor closes the Session J. s.beginTransaction() s = sf.openSession() s.setFlushMode(MANUAL) MSC.bind(s) commit() s = MSC.unbind() 1. 2. 3. 4. s.beginTransaction() commit() 6. 8. MSC.bind(s) 5. 7. s = MSC.unbind() 9. s.close() s.flush() Figure 11.4 Interception of events to manage the lifecycle of a Session Conversations with Hibernate 495 This sounds more complex than it is in code. Listing 11.5 is a pseudoimple- mentation of such an interceptor: public class ConversationInterceptor { public Object invoke(Method method) { // Which Session to use? Session currentSession = null; if (disconnectedSession == null) { // Start of a new conversation currentSession = sessionFactory.openSession(); currentSession.setFlushMode(FlushMode.MANUAL); } else { // In the middle of a conversation currentSession = disconnectedSession; } // Bind before processing event ManagedSessionContext.bind(currentSession); // Begin a database transaction, reconnects Session currentSession.beginTransaction(); // Process the event by invoking the wrapped execute() Object returnValue = method.invoke(); // Unbind after processing the event currentSession = ManagedSessionContext.unbind(sessionFactory); // Decide if this was the last event in the conversation if ( returnValue.containsEndOfConversationToken() ) { // The event was the last event: flush, commit, close currentSession.flush(); currentSession.getTransaction().commit(); currentSession.close(); disconnectedSession = null; // Clean up } else { // Event was not the last event, continue conversation currentSession.getTransaction().commit(); // Disconnects disconnectedSession = currentSession; } return returnValue; } } Listing 11.5 An interceptor implements the session-per-conversation strategy 496 CHAPTER 11 Implementing conversations The invoke(Method) interceptor wraps around the execute() operation of the controller. This interception code runs every time a request from the application user has to be processed. When it returns, you check whether the return value contains a special token or marker. This token signals that this was the last event that has to be processed in a particular conversation. You now flush the Session , commit all changes, and close the Session . If this wasn’t the last event of the con- versation, you commit the database transaction, store the disconnected Session , and continue to wait for the next event in the conversation. This interceptor is transparent for any client code that calls execute() . It’s also transparent to any code that runs inside execute () : Any data access opera- tion uses the current Session ; concerns are separated properly. We don’t even have to show you the data-access code, because it’s free from any database transac- tion demarcation or Session handling. Just load and store objects with getCur- rentSession() . The following questions are probably on your mind: ■ Where is the disconnectedSession stored while the application waits for the user to send the next request in a conversation? It can be stored in the HttpSession or even in a stateful EJB. If you don’t use EJBs, this responsibility is delegated to your application code. If you use EJB 3.0 and JPA, you can bind the scope of the persistence context, the equivalent of a Session , to a stateful EJB— another advantage of the simplified programming model. ■ Where does the special token that marks the end of the conversation come from? In our abstract example, this token is present in the return value of the exe- cute() method. There are many ways to implement such a special signal to the interceptor, as long as you find a way to transport it there. Putting it in the result of the event processing is a pragmatic solution. This completes our discussion of persistence-context propagation and conversa- tion implementation with Hibernate. We shortened and simplified quite a few examples in the past sections to make it easier for you to understand the con- cepts. If you want to go ahead and implement more sophisticated units of work with Hibernate, we suggest that you first also read chapter 16. On the other hand, if you aren’t using Hibernate APIs but want to work with Java Persistence and EJB 3.0 components, read on. Conversations with JPA 497 11.3 Conversations with JPA We now look at persistence context propagation and conversation implementa- tion with JPA and EJB 3.0. Just as with native Hibernate, you must consider three points when you want to implement conversations with Java Persistence: ■ You want to propagate the persistence context so that one persistence con- text is used for all data access in a particular request. In Hibernate, this functionality is built in with the getCurrentSession() feature. JPA doesn’t have this feature if it’s deployed stand-alone in Java SE. On the other hand, thanks to the EJB 3.0 programming model and the well-defined scope and lifecycle of transactions and managed components, JPA in combination with EJBs is much more powerful than native Hibernate. ■ If you decide to use a detached objects approach as your conversation implementation strategy, you need to make changes to detached objects persistent. Hibernate offers reattachment and merging; JPA only supports merging. We discussed the differences in the previous chapter in detail, but we want to revisit it briefly with more realistic conversation examples. ■ If you decide to use the session-per-conversation approach as your conversa- tion implementation strategy, you need to extend the persistence context to span a whole conversation. We look at the JPA persistence context scopes and explore how you can implement extended persistence contexts with JPA in Java SE and with EJB components. Note that we again have to deal with JPA in two different environments: in plain Java SE and with EJBs in a Java EE environment. You may be more interested in one or the other when you read this section. We previously approached the sub- ject of conversations with Hibernate by first talking about context propagation and then discussing long conversations. With JPA and EJB 3.0, we’ll explore both at the same time, but in separate sections for Java SE and Java EE. We first implement conversations with JPA in a Java SE application without any managed components or container. We’re often going to refer to the differences between native Hibernate conversations, so make sure you understood the previ- ous sections of this chapter. Let’s discuss the three issues we identified earlier: per- sistence context propagation, merging of detached instances, and extended persistence contexts. 498 CHAPTER 11 Implementing conversations 11.3.1 Persistence context propagation in Java SE Consider again the controller from listing 11.1. This code relies on DAOs that exe- cute the persistence operations. Here is again the implementation of such a data access object with Hibernate APIs: public class ItemDAO { public Bid getMaxBid(Long itemId) { Session s = getSessionFactory().getCurrentSession(); return (Bid) s.createQuery(" ").uniqueResult(); } } If you try to refactor this with JPA, your only choice seems to be this: public class ItemDAO { public Bid getMaxBid(Long itemId) { Bid maxBid; EntityManager em = null; EntityTransaction tx = null; try { em = getEntityManagerFactory().createEntityManager(); tx = em.getTransaction(); tx.begin(); maxBid = (Bid) em.createQuery(" ") .getSingleResult(); tx.commit(); } finally { em.close(); } return maxBid; } } No persistence-context propagation is defined in JPA, if the application handles the EntityManager on its own in Java SE. There is no equivalent to the getCur- rentSession() method on the Hibernate SessionFactory . The only way to get an EntityManager in Java SE is through instantiation with the createEntityManager() method on the factory. In other words, all your data access methods use their own EntityManager instance—this is the session-per- operation antipattern we identified earlier! Worse, there is no sensible location for transaction demarcation that spans several data access operations. There are three possible solutions for this issue: [...]... propagation is available with thread or JTA transaction binding in Java SE and Java EE Persistence contexts are either scoped to the transaction, or managed by the application Java Persistence standardizes a persistence context propagation model for Java EE only, deeply integrated with EJB 3.0 components Persistence context scoping, to transactions or to stateful session beans, is well defined Hibernate supports... how FlushMode.MANUAL, a Hibernate feature, can disable flushing of your persistence context independently from your transaction assembly Table 11.2 shows a summary you can use to compare native Hibernate features and Java Persistence 516 CHAPTER 11 Implementing conversations Table 11.2 Hibernate and JPA comparison chart for chapter 11 Hibernate Core Java Persistence and EJB 3.0 Persistence context propagation... extended persistence context strategy are often easier to understand than applications that rely heavily on detached objects 11.3.3 Extending the persistence context in Java SE We already discussed the scope of a persistence context with JPA in Java SE in chapter 10, section 10.1.3, “Transactions with Java Persistence. ” Now we elaborate on these basics and focus on examples that show an extended persistence. .. for transitive persistence The best known is persistence by reachability; we discuss it first Although some basic principles are the same, Hibernate uses its own, more powerful model, as you’ll see later The same Transitive persistence 519 is true for Java Persistence, which also has the concept of transitive persistence and almost all the options Hibernate natively provides 12.1.1 Persistence by reachability... modification replicate org .hibernate. annotations.CascadeType.REPLICATE Hibernate navigates the association and cascades the replicate() operation to associated objects evict org .hibernate. annotations.CascadeType.EVICT Hibernate evicts associated objects from the persistence context when an object is passed to evict() on the Hibernate Session refresh javax .persistence. CascadeType.REFRESH Hibernate rereads the... in Java SE and with EJBs On the other hand, persistence- context propagation and extended persistence- context management with JPA become much easier when you introduce EJBs and then rely on the standardized context propagation rules and the integration of JPA with the EJB 3.0 programming model Let’s first focus on the persistence- context propagation in EJB invocations 11.4.1 Context propagation with. .. detached instances persist javax .persistence. CascadeType.PERSIST Hibernate makes any associated transient instance persistent when an object is passed to persist() If you use native Hibernate, cascading occurs only at call-time If you use the EntityManager module, this operation is cascaded when the persistence context is flushed merge Javax .persistence. CascadeType.MERGE Hibernate navigates the association... between the Hibernate vendor extension with FlushMode.MANUAL and the official approach with nontransactional operations Disabling flushing with a Hibernate extension Let’s first write a stateful EJB, the conversation controller, with the easier Hibernate extension: @Stateful @TransactionAttribute(TransactionAttributeType.REQUIRED) public class ManageAuctionBean implements ManageAuction { @PersistenceContext(... conversation implementation with detached objects, these objects can be reattached or merged during a conversation Java Persistence standardizes merging of detached objects, but has no support for reattachment Hibernate supports disabling automatic flushing of persistence contexts for long conversations with the FlushMode.MANUAL option Disabling automatic flushing of an extended persistence context requires... most efficient processing options You should be familiar with the basic object states and the persistence interfaces; the previous chapters are required reading to understand this chapter First we’ll show you how transitive persistence can make your work with complex object networks easier The cascading options you can enable in Hibernate and Java Persistence applications significantly reduce the amount . Conversations with JPA 4 97 11.3 Conversations with JPA We now look at persistence context propagation and conversation implementa- tion with JPA and EJB 3.0. Just as with native Hibernate, you. a persistence context with JPA in Java SE in chapter 10, section 10.1.3, “Transactions with Java Persistence. ” Now we elaborate on these basics and focus on examples that show an extended persistence. conversations with Java Persistence: ■ You want to propagate the persistence context so that one persistence con- text is used for all data access in a particular request. In Hibernate, this functionality