Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Multi-threaded overwrites
Multi-threaded overwrites [message #1001948] Thu, 17 January 2013 10:43 Go to next message
Justin Stewart is currently offline Justin Stewart
Messages: 6
Registered: September 2012
Junior Member
Hi, all -
I'm new to EclipseLink, so this may be easy.
I'm using version 2.4.1 in Virgo 3.5.

So here's the problem. I have entity classes A and B, which have a one-to-one relationship with each other. Here's the order of events that reproduces the problem:
1. Thread 1 reads instance A(1) of type A.
2. Thread 2 reads instance B(1) of type B that is linked to A(1) by the one-to-one relationship.
3. Thread 1 changes A(1) and merges/flushes it to the database.
4. Thread 2 changes B(1) and merges/flushes it to the database. In the process of this write, the change that was made to A(1) by thread 1 is overwritten in the database - and the old contents of A(1) are written. This is because in the one-to-one definition of B to A, I had cascade/cascade-all. So a write to B(1) cascaded to a write of A(1). And the instance of A(1) held by thread 2 was not affected by the changes made by thread 1. Removing the cascade fixed this problem.

My concern is the bigger picture where I won't have this workaround.
In an environment like Virgo, multiple threads is the norm. If each thread may operate on different entity instances representing the same row in the database - and their actions are not coordinated or cooperative, there is not much hope of maintaining data integrity.

Is there something I am missing in terms of usage or best practices?
Granted, the eclipselink.cache.shared.default property has been set to false in this project for some reason - and this may be the cause. If these entity instances were proxies to a single cached object, it seems that changes to any entity would be reflected across all proxy instances.

Any thoughts? Thanks.
Justin
Re: Multi-threaded overwrites [message #1002414 is a reply to message #1001948] Fri, 18 January 2013 09:34 Go to previous message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Cascade merge can be dangerous if you are not using some form of version locking to prevent overwriting with stale data, and stale data can occur even within a single threaded app if care isn't taken. Optimistic locking is always recommended

Some general JPA best practices with a brief mention of Optimistic Locking:
http://wiki.eclipse.org/EclipseLink/FAQ/JPA/BestPractices#M2._Use_optimistic_locking

Notes on Optimistic locking itself:
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking/Optimistic_Locking

Best Regards,
Chris
Previous Topic:Parameterized SessionCustomizer with spring (or without)
Next Topic:EclipseLink and pagined queries
Goto Forum:
  


Current Time: Thu Jul 24 11:22:56 EDT 2014

Powered by FUDForum. Page generated in 0.01523 seconds