| postponed database writes [message #1233768] |
Mon, 20 January 2014 07:31  |
Eclipse User |
|
|
|
Is it possible to postpone any database write actions?
The idea behind this is that in a fat client, you cannot have a transaction open and keep updating records in the database, that would negate the use of optimistic locking. But, similar to a web request, you have to wait until the user presses a save button and then write out all changes in one burst. Basically this means that the EM is used to fetch entities, entities are created and modified, but no database write until that save (submit) button.
Regards, Tom
|
|
|
|
| Re: postponed database writes [message #1234531 is a reply to message #1234225] |
Wed, 22 January 2014 02:32  |
| Eclipse User |
|
|
|
It is exactly like you say: "query forces a flush". Imagine a fat Swing application with a JPA layer; the minute the application writes something to the database, a jdbc transaction will be opened and a database write lock is placed, effectively locking out all other access until the transaction is committed or rolled back. And that can take a very very long time, and even result in an transaction timeout because the user left the keyboard. JPA may be doing optimistic locking, but it is behaving like pessimistic locking.
IMHO a fat client requires the persistency layer to not write anything at all, until the user hits "save". Then it should attempt to burst write, using optimistic locking, all changes that were made; being persist, removes, merges or changes to managed beans.
Effectively the behavior should be that one constructs a 100% in memory model, which is than synced to the persisted one.
On 2014-1-21 14:48, Chris Delahunt wrote:
> I'm not sure the question. What you describe is the JPA model - you read through an EM and can make changes, but only commit later on. Writes do not occur unless flush or commit are called, or some query forces a flush.
>
> Best regards,
> Chris
|
|
|
Powered by
FUDForum. Page generated in 0.03641 seconds
Home