|
|
| Re: postponed database writes [message #1234531 is a reply to message #1234225] |
Wed, 22 January 2014 07:32  |
 Tom Eugelink
Messages: 817
Registered: July 2009 |
Senior Member |
|
|
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.02740 seconds
] 
Search
Help
Register
Login
Home
