Hi, 1. If locking is less of a priority then performance, then use <property name="openjpa.LockManager" value="none"/>
By default, OpenJPA goes for optimistic lock mode. So as Kevin pointed out, without @Version and default Optimistic lock mode -- many wasted SQL to compare state for version checking. However, one should be aware of data integrity risks in such cases. Without any locking and no version field, OpenJPA essentially will follow a "last-write-wins" straegy. But as updates happen at per-field basis, something like this can happen Transaction 1: Reads a Person P whose first name is 'John' and last name is 'Doe' Transaction 2: Reads the same Person Transaction 1: Modifies first name to 'Harry' and commits Transaction 2: Modified last name to 'Smith' and commits. Both commit will succeed and database will have 'Harry Smith'. 2. Build-time enhancement i.e. to execute one command after compilation performs best and minimizes complexity of load-time-weaving. I have never understood what really makes people to avoid 'build-time enhancement' - especially when most of the apps are built, packaged and deployed via Ant/Maven. is_maximum wrote: > > Hi Kevin, > > Well now there are some questions here, > first, consider the App Server dosn't enable enhancer how can I tell my > App server to activate it? Do I have to use the same javaagent.... > property? > > second, We just neglected the version field and I didn't know the OpenJPA > will use optimistic locking anyway. Is there any way to disable this kind > of locking? At the time we call the merge() method I can see the row in > target table in Oracle is being locked so this means that we are using > pessimistic locking, Am I right? > > One more question is that if we are using optimistic locking how to handle > it? if a request changes an entity say Account, and at the same time there > are say 10 requests that are modifying the same account, the first request > will commit its changes and all other 10 requests will fail because their > fetched entity is no longer valid. As I know using optimistic locking is > not a good option for the entities with very frequent update actions. > > > -- View this message in context: http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2237146.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
