openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dirk Brenckmann" <Brenckmann.Sourcefo...@gmx.de>
Subject Re: Callback to/from entity transactions
Date Fri, 04 Jul 2008 11:27:42 GMT
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.

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?
Maybe there are docs that cover 'openjpa persistence strategies' in more detail?
-- 
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

Mime
View raw message