So your situation is that you are updating non-detached entities and usually
(but possibly not always) want optimistic locking. This can be handled on a
case-by-case basis without altering Hibernate's internals. Look for
"bulkEditPersonsByDTOs" in:
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formloop1
It's using JPA but the technique is the same (and in this case JPA is
implemented with Hibernate by the demo's container, JBoss).
Cheers,
Geoff
On 06/12/2012, at 1:51 AM, nquirynen wrote:
> Just for the interested:
>
> After some more research I found that setting the version manually (which is
> not recommended by Hibernate) didn't work because of what is described here:
> https://forum.hibernate.org/viewtopic.php?p=2293177&sid=2969aa867c7086b4a3c7a68bda853690#p2293177
>
> It's a really old post, but the solution he provides in that thread seems to
> work and feels like the most clean solution to me. Also I cannot find alot
> about this topic, and especially no real response from the Hibernate team
> themself.
>
> So what I have now:
>
> 1) Hidden field for the entities version
> 2) implementation of FlushEntityEventListener with onFlushDirty() method
> containing a check on the version which throws a StaleObjectStateException
> when needed
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Tapestry-Hibernate-optimistic-locking-tp5718413p5718501.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
