Detached entities, version attribute and optimistic concurrency control

2009-11-14 Thread Nikhil Patwardhan

Hi,

I'm new to OpenJPA and I have been trying to create a small prototype
demonstrating how I can use it as a JPA compliant persistence provider in a
J2EE web applications. In one of my use cases, I do the following: 

1) Look up an entity(Class name:Document, for instance) using em.find() in
the service layer. The entity has a version field. 

2) Detach the entity by closing the em.

3) Pass the detached entity to the presentation layer (a JSP) which shows a
screen to update various fields of the entity. The UI also has a field for
the version attribute which is sent back on submit.

4) Submit the data back, create a new Document object, set the fields and
call em.merge(document) inside a transaction.

This code fails in step 4 with the following exception when I try to set the
version attribute on the Document object before calling merge().
---
org.apache.openjpa.persistence.InvalidStateException: Detected attempt to
modify field core.persistence.Document.docVer with value strategy
restrict.

Am I missing something here? My approach here is to set the version
attribute obtained from the UI on the entity to be merged so that optimistic
concurrency control would come into play to find out 
if the entity has been updated since the last read. If version attribute
cannot be set on an entity, I might have to keep the detached entity
obtained from find() in HttpSession and then use it when the updated data is
submitted. But I'm wondering if keeping entities in session is a good idea,
as it can make the session bloated with entities.

-- 
View this message in context: 
http://n2.nabble.com/Detached-entities-version-attribute-and-optimistic-concurrency-control-tp4003522p4003522.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Re: Detached entities, version attribute and optimistic concurrency control

2009-11-14 Thread Marc Logemann

Hi,

i dont get why you manually want to modify the JPAVERSION attribute.

If you dont want to keep the detached object in the session (thats  
what we do), you
must at least remember the OID (object id) of the Document, find it  
again from the

persistenceManager and then do the changes on the object and
persist/merge again.

Manually setting the version attribute makes no sense at all because  
you really want the
ORM layer to manage the version attribute and only he knows best when  
someone

modified your data and throws an OptimisticException when this happened.

Regarding the bloated HTTPSession. We just speak of a CRUD based  
application where
you are just on the way modifying a record dont you? How big can the  
object model
for that specific GUI can be? After that you can easily remove the  
detached entities

from the session.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 14.11.2009 um 09:38 schrieb Nikhil Patwardhan:



Hi,

I'm new to OpenJPA and I have been trying to create a small prototype
demonstrating how I can use it as a JPA compliant persistence  
provider in a

J2EE web applications. In one of my use cases, I do the following:

1) Look up an entity(Class name:Document, for instance) using em.find 
() in

the service layer. The entity has a version field.

2) Detach the entity by closing the em.

3) Pass the detached entity to the presentation layer (a JSP) which  
shows a
screen to update various fields of the entity. The UI also has a  
field for

the version attribute which is sent back on submit.

4) Submit the data back, create a new Document object, set the  
fields and

call em.merge(document) inside a transaction.

This code fails in step 4 with the following exception when I try to  
set the

version attribute on the Document object before calling merge().
---
org.apache.openjpa.persistence.InvalidStateException: Detected  
attempt to

modify field core.persistence.Document.docVer with value strategy
restrict.

Am I missing something here? My approach here is to set the version
attribute obtained from the UI on the entity to be merged so that  
optimistic

concurrency control would come into play to find out
if the entity has been updated since the last read. If version  
attribute

cannot be set on an entity, I might have to keep the detached entity
obtained from find() in HttpSession and then use it when the updated  
data is
submitted. But I'm wondering if keeping entities in session is a  
good idea,

as it can make the session bloated with entities.

--
View this message in context: 
http://n2.nabble.com/Detached-entities-version-attribute-and-optimistic-concurrency-control-tp4003522p4003522.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.