Callback to/from entity transactions
|
|
|
|
||||||||
|
This is "the" reason for the EntityManager.flush() method that gives
you immediate feedback if there is some application reason to fail the transaction. If flush() succeeds, the only reason for failing a transaction is outside your (application) control. Craig On Jul 3, 2008, at 8:57 AM, Dirk Brenckmann wrote: > Hi, > > Q: Is there a way to access/get back exceptions thrown within the > persistance/transaction layer? > > Example: > Code (pseudo): > Sateless session bean::SomeEntity someMethod( SomeEntity > entity ) { > return this.getEntityManager().merge( entity ); > } > > Server: > Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: > Duplicate entry '0-shortname 1-0000-00-00 00:00:00' for > key 2 > > Client: > Will get SomeEntity with all fields set to null/default. > > > Well - I would have expected something like 'null' to be returned or > an exception to be thrown, but I have to admit I did not yet fully > read the specs... Nvm I can handle the returned value anyway. > But: > I'd like to give the user a feedback like "... already exists!" > which I can do soley if I get access to the exception thrown on the > transaction layer. Is there something like @TransactionCallback? > Or maybe I went wrong somwhere else? > > Thank you in advance. > -- > Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? > Der Eine für Alle: http://www.gmx.net/de/go/messenger03 Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@... P.S. A good JDO? O, Gasp! |
||||||||
smime.p7s (3K) |
|
In reply to this post by Dirk Brenckmann
|
||||||||
|
|
Hi Dirk,
On Jul 4, 2008, at 4:27 AM, Dirk Brenckmann wrote: > Craig L Russell: >> This is "the" reason for the EntityManager.flush() method that >> gives you >> immediate feedback if there is some application reason to fail the >> transaction. > > Ty for your quick response. > > I'm not this sure if I want this to be "the" reason for calling a > flush(). I'd call a flush if the next DB query would need the > previous data released to the database before being executed. dependent on information in the persistence context. > > > Having a stateless(?) bean calling flush anytime after a merge > occurs, just to be sure it did not fail, might result in a large > overhead. E.g. a batch merge: > > List<MyEntity> entities = ... > for ( MyEntity entity : entities ) { > manager.merge( entity ); > try { manager.flush(); } > catch( ... t ) { > throw new UserfeedBackException( "Updating <eintity> failed > due to: ", t ); > } > } > > If I want to get rid of <many> calls to flush(), I finally might not > know which entity failed the merge: > > List<MyEntity> entities = ... > for ( MyEntity entity : entities ) { > manager.merge( entity ); > } > try { manager.flush(); } > catch( ... t ) { > throw new UserfeedBackException( "Updating <???> failed due > to: ", t ); > } > > Which finally leads me to the question if flush() is a 'lightweight' > or a 'heavyweight' call? than telling the entity manager that an instance is to be persisted. And flush is a coarse-grained operation, effectively synchronizing the entire persistence context with the database. > > Maybe there are docs that cover 'openjpa persistence strategies' in > more detail? OpenJPA tries to defer processing until the last flush before commit. This is to allow efficient operation such as batching inserts, updates, and deletes. The JPA specification is deliberately vague on when changes to the persistence context are propagated to the database, since different products (JDO, Hibernate, and TopLink) had different semantics. Also note that in an optimistic transaction scenario, as soon as you modify the database using a connection, that connection must remain bound to that transaction until the transaction completes. Which means that the bound connection is removed from the available connection pool for the duration of the transaction. So by requiring early modification the overall system performance might be affected. That said, I think that there is value in fine-grained propagation strategies, one of which you mention. Sometimes efficiency is trumped by information. In your case, it sounds like you'd rather suffer potential performance degradation in exchange for more information as to what failed. One possibility is to allow a flag to specify under what circumstances OpenJPA should go to the database: persist (the insert could throw duplicate key exception); delete (the delete could throw no such entity exception); merge (the select could throw no such entity exception). Craig > > -- > GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! > Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@... P.S. A good JDO? O, Gasp! |
||||||||
|
|
||||||||
| Free Forum Powered by Nabble | Forum Help |