Hi guys, I'm afraid, but it does not work at all. As per the spec, interceptors are part of the transaction itself, so it won't receive the OptimisticLockingException except if you explicitly call a flush in the bean's method. Otherwise, the exception will occur at the commit phase (outside the interceptor). Otherwise, you need to switch to BMT (instead of CMT) and do the transaction stuff yourself which is far more painless than calling flush when it makes sense for business.
Moreover, from my own experience, it looks a bad idea to retry in such a blind manner because it can lead to unpredictable responses time. Calling more than once the business method could override previous changes. Finally, it's IMHO more a business concern than a technical concern. Most of the time, when you receive a concurrent issue, you should inform the user that something happened during his changes and it needs to take them into account. The best and cleaner manner in my opinion is to call flush in the business method where that can happen (which is not too often). And rethrown a business error to the client to let him decide what is relevant in that case. Just some thoughts, Jean-Louis 2012/10/29 Bertrand Guay-Paquet <[email protected]> > Hi, > > I had something to this effect in my "todo list": > http://blog.vacs.fr/index.php?**post/2010/06/27/Fault-** > tolerant-EJB-interceptor%3A-a-**solution-to-optimistic-** > locking-errors-and-other-**transient-faults<http://blog.vacs.fr/index.php?post/2010/06/27/Fault-tolerant-EJB-interceptor%3A-a-solution-to-optimistic-locking-errors-and-other-transient-faults> > > It's an interceptor which catches exceptions. You could use it to rethrow > your own exception when an optimistic lock exception occurs. > > disclaimer: I haven't tried it yet. > > Bertrand > > > On 29/10/2012 7:47 AM, Jean-Louis MONTEIRO wrote: > >> There is no trivial way to get that in the client cause the spec requires >> it to be wrapped. >> As the exception is thrown during commit (flush at least), you can in the >> business method (ie. the session bean method) force a em.flush() to >> propagate the persistence context to the database and get all relational >> constraints validated by the database. >> Around the flush statement, you can catch the Optimistic Lock exception >> and >> throw a business exception. >> >> That's the best way from a design point of view to do and to deal with >> such >> a situation. >> >> Jean-Louis >> >> >> 2012/10/29 Romain Manni-Bucau <[email protected]> >> >> hi, >>> >>> can you share the whole stack please? >>> >>> *Romain Manni-Bucau* >>> *Twitter: @rmannibucau >>> <https://twitter.com/**rmannibucau<https://twitter.com/rmannibucau> >>> >* >>> *Blog: >>> **http://rmannibucau.**wordpress.com/*<http://rmannibucau.wordpress.com/*> >>> < >>> http://rmannibucau.wordpress.**com/ <http://rmannibucau.wordpress.com/>> >>> *LinkedIn: >>> **http://fr.linkedin.com/in/**rmannibucau*<http://fr.linkedin.com/in/rmannibucau*> >>> *Github: https://github.com/**rmannibucau*<https://github.com/rmannibucau*> >>> >>> >>> >>> >>> 2012/10/29 knak55 <[email protected]**> >>> >>> Hi, >>>> >>>> I am trying to migrate an application which works on Glassfish 3.1.2.2to >>>> TomEE 1.5. >>>> The application calls each component like this : JSF -> CDI -> >>>> Stateless >>>> EJB -> JPA -> DB >>>> On the Glassfish, a program(CDI) in the web tire can handle the >>>> “OptimisticLockException” with the following code successfully. >>>> >>>> : >>>> } catch (Exception e) { >>>> if (e.getCause() instanceof >>>> javax.persistence.**OptimisticLockException) { >>>> : >>>> >>>> However, on the TomEE 1.5, we got javax.transaction.** >>>> RollbackException >>>> instead of >>>> javax.persistence.**OptimisticLockException. >>>> >>>> How can I catch “OptimisticLockException” in the CDI? >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>>> http://openejb.979440.n4.**nabble.com/How-can-I-catch-** >>> OptimisticLockException-**tp4658313.html<http://openejb.979440.n4.nabble.com/How-can-I-catch-OptimisticLockException-tp4658313.html> >>> >>>> Sent from the OpenEJB User mailing list archive at Nabble.com. >>>> >>>> >
