Hi Romain, Well in the else block the DTO and the Entity will both be new so the version will never be set.
Andy. Thanks, I am aware of this basic rule but I got confused by reading several times that if you use DTO remember to care for the version field. However I guess this means I am supposed to throw ApplicationException rollback=true myself when I discover that the DTO is old... This actually makes sense because the logic required for optimistic lock management is custom and it's also more efficient for me to throw while I convert back to entity. By the way when I am testing optimistic locking @Test(expected=MyApplicationException) works poorly, seems that at least for tests it gets wrapped with EJBException. I am pretty sure I managed to make it ApplicationException correctly because otherwise the exception / logging hints that ApplicationException could be used instead to avoid the wrapping. cheers On 14 May 2014 20:19, agumbrecht <[email protected]> wrote: > You should let the JPA provider manage the @Version field, don't try and > change it or read it yourself or you'll always get this error. It's > controlled internally by the provider and is to do with optimistic locking. > > If you want to manage your own entity version the, i.e. versioned data row, > then use a different name/field and treat it like any other field - Don't > flag it with @Version. > > Hope this helps. > > Andy. > > > > ----- > -- > Andy Gumbrecht > > http://www.tomitribe.com > [email protected] > https://twitter.com/AndyGeeDe > > TomEE treibt Tomitribe ! | http://tomee.apache.org > -- > View this message in context: > http://openejb.979440.n4.nabble.com/OpenJPA-and-DTO-problem-tp4669332p4669334.html > Sent from the OpenEJB User mailing list archive at Nabble.com. >
