I also suggested an option to do a query first and check if such instance
already exist, then decide whether to call em.persist() or not :). Tx rollback
is never optimized, so if you have it often, the query will be faster.
But I'm glad you have a solution.
Regards,
-marina
Felipe Gaścho wrote:
> finally I understood the problem..
>
> Marina was right, I need to declare requiresNew transaction in the
> sub-transaction, otherwise the JMS transaction will rollback together
> with the JPA one :(
>
> thanks a lot for the tips, now it is time to refactor and blog <- to
> not forget anymore :)
>
> 2009/9/23 Felipe Gaścho <fgaucho_at_gmail.com>:
>
>>Thank you very much.. I will try this..
>>
>>the exception is
>>
>>MDB's onMessage() {
>> call EntityManager.persist and this throws an EntityAlreadyExists
>>Exception...
>>}
>>
>>the root of the redelivery is a JPA exception .. I am not sure if
>>there is a relationship between this and the JMS behavior
>>
>>On Wed, Sep 23, 2009 at 12:24 AM, Nigel Deakin <Nigel.Deakin_at_sun.com> wrote:
>>
>>>Felipe Gaścho wrote:
>>>
>>>>there is no mechanism in Glassfish where I can say: "stop after
>>>>n-trials", doesn't matter what.. to preserve the server ?
>>>
>>>If an exception is being thrown in the MDB's onMessage() method, and you're
>>>using the JMSRA resource adapter, the redelivery of messages should be
>>>controlled by the ActivationSpec properties
>>>endpointExceptionRedeliveryAttempts and sendUndeliverableMsgsToDMQ.
>>>
>>>endpointExceptionRedeliveryAttempts (default=6) specifies the "Number of
>>>times to redeliver a message when MDB throws an exception during message
>>>delivery"
>>>
>>>sendUndeliverableMsgsToDMQ (default=true) specifies that MQ should "Place
>>>message in dead message queue when MDB throws a runtime exception and number
>>>of redelivery attempts exceeds the value of
>>>endpointExceptionRedeliveryAttempts"
>>>
>>>http://docs.sun.com/app/docs/doc/820-6740/aeoon?a=view
>>>
>>>Does this match what you are seeing?
>>>
>>>Nigel
>>>
>>>
>>>
>>>>2009/9/22 Felipe Gaścho <fgaucho_at_gmail.com>:
>>>>
>>>>>may I force the transaction on the JMS Queue ??
>>>>>
>>>>>2009/9/22 Felipe Gaścho <fgaucho_at_gmail.com>:
>>>>>
>>>>>>Yes, I know.. and I will verify.. problem is: anytime any problem
>>>>>>happens in the code, it destroy the Glassfish instance and makes the
>>>>>>machine itself useless due to the amount of log files generated by the
>>>>>>deadlock..
>>>>>>
>>>>>>Is there a way to prevent that ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>I tought a try-catch(Exception) would stop the exception fall :(
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>Looking for a client application for this service:
>>>>>http://fgaucho.dyndns.org:8080/footprint-service/wadl
>>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>
>>
>>
>>--
>>Looking for a client application for this service:
>>http://fgaucho.dyndns.org:8080/footprint-service/wadl
>>
>
>
>
>