tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Optimi sticLockException: Optimistic locking errors were detected when flushing to the data store
Date Mon, 28 Jan 2013 08:12:43 GMT
Hi,

all operations done in a transaction are done at commit time but the order
is never guaranteed by any providers (in fact most of them doesn't respect
it at all). So i'm pretty sure that's not the exact reason

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/1/28 BKumar <bibhuti.kumar@creditpointe.com>

> It seems I  have identified the possible reason.
> In my  code first  I am  calling child remove then  parent remove.This is
> the most Ideal  way of working the remove.
> But in Tomee+ it seems when transaction is commit, it is first calling
> parent remove and then  child remove and at the same time database cascade
> is also trying to  delete child because it is getting triggered by  parent
> delete.
>
> Is there any way in OpenEjb such that at  commit it maintain the order of
> calling remove as in the code?
>
> Thanks,
> Bibhuti
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Optimi-sticLockException-Optimistic-locking-errors-were-detected-when-flushing-to-the-data-store-tp4660338p4660429.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message