Sure, it's rev 19928: I register both a TX synchronization and a before
completion process. So:
* for a JTA environment, part of the audit records will be written in the
before completion process (if there was a manual flush), and part in the tx
sync (automatic flush). Both propagate exceptions
* in a resource-local env, all audit records will be written in the before tx
completion process, and so all exceptions propagated
But this is really a hack, I think the inconsistency should be fixed :).
On Jul 11, 2010, at 5:53 PM, Emmanuel Bernard wrote:
> Ahhhh, Hibernate Search has the same problem but I could not pin point the
> issue.
> Can you point me to the temp patch approach you're using.
>
> On 10 juil. 2010, at 10:05, Adam Warski wrote:
>
>> Hello,
>>
>> because the thread is a bit old a small reminder what it was about:
>> Envers used TX Synchronizations to write the audit data to a database,
>> before the transaction completed. However, exceptions thrown during a
>> synchronization are "eaten" (JDBCTransaction:274). The solution then was to
>> use, instead of a Synchronization, a BeforeTransactionCompletionProcess.
>>
>> This, however, as it turns out, causes big problems in a JTA environment
>> (with resource-local txs all works fine): audit records are sometimes not
>> written. This is because the before tx completion process is called before
>> tx synchronizations, and in JTA the auto-flush at the end of a session is
>> done using a TX synchronization (AbstractEntityManagerImpl:1020). And it
>> doesn't look like exceptions are eaten when thrown from a synchronization in
>> JTA - otherwise any exception that occurred during a flush would go
>> unnoticed (and I know from practice this doesn't happen ;) ).
>>
>> So isn't this inconsistent? Shouldn't the exceptions in JDBCTransaction be
>> rethrown as well?
>>
>> For now a fix is to register both a BTCP and a TX Sync to write the audit
>> records, but I'd say it's rather a temporary patch :)
>>
>> On Mar 31, 2010, at 1:00 PM, Adam Warski wrote:
>>
>>>
>>>> In an ideal world, a Synchronization should swallow exceptions (or do
>>>> whatever it wants with it) if the exception should not tamper with the
>>>> main Hibernate execution. In a word, Synchronization would be in control.
>>>> It has my preference but It's a change of semantic.
>>>
>>> Then maybe do as Steve suggested, either:
>>> - introduce a new method to Synchronization (that would break existing
>>> synchronizations)
>>> or
>>> - introduce a new interface SynchronizationRollback which can be optionally
>>> implemented by the synchronization method
>>> Then in JDBC transaction we could do:
>>>
>>> if ((sync instanceof SynchronizationRollback) && ((SynchronizationRollback)
>>> sync).shouldRollback(exception) { // rollback }
>>>
>>> --
>>> Adam Warski
>>> http://www.warski.org
>>> http://www.softwaremill.eu
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> Adam Warski
>> http://www.warski.org
>> http://www.softwaremill.eu
>>
>>
>>
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
