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/[EMAIL PROTECTED]
