Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » postponed database writes
postponed database writes [message #1233768] Mon, 20 January 2014 12:31 Go to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 807
Registered: July 2009
Senior Member
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 #1234225 is a reply to message #1233768] Tue, 21 January 2014 13:48 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1034
Registered: July 2009
Senior Member
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
Re: postponed database writes [message #1234531 is a reply to message #1234225] Wed, 22 January 2014 07:32 Go to previous message
Tom Eugelink is currently offline Tom Eugelink
Messages: 807
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
Previous Topic:virtual mapping for byte[]
Next Topic:Performance Question - eclipselink.jdbc.cache-statements
Goto Forum:
  


Current Time: Sat Oct 25 18:22:48 GMT 2014

Powered by FUDForum. Page generated in 0.02777 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software