For the sake of posterity (by which I mean my awful memory)...
We discussed this on IRC and really we have 2 discussions here, both
related to how the Hibernate Transaction API treats registered syncs:
1) The choice of whether to ignore/rethrow exceptions from the syncs
2) The problem with envers
On 10 juil. 2010, at 09:05, Adam Warski wrote:
> 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
> synchronizatio
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
A, 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 Synchroniz
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,
> 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 St
I tend to agree. The problem today is that you cannot forward / signal the
exception to the upper levels.
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, Synchroniza
Hello,
> The main reason is because allowing these exceptions to be (re-)thrown
> opens up mixed heuristic issues.
>
> Also bear in mind that we have no clue about the nature of the process
> being performed by the synch. It highly likely that "failure" of the
> synch should *not* rollback th
Hi!
The sync is actually rolling back the main transaction, but there is no way
to indicate upper layers about it because hibernate calls commit()
succesfully after syncs.
Could we think about adding a new exception to be throwed by the
JDBCTransaction? In that case this exception is thrown by a s
The main reason is because allowing these exceptions to be (re-)thrown
opens up mixed heuristic issues.
Also bear in mind that we have no clue about the nature of the process
being performed by the synch. It highly likely that "failure" of the
synch should *not* rollback the main transaction.
> interesting,
> Hibernate Search is affected by this, but I thought the current
> problem was due to the fact that work is being executed in another
> thread.
Also, probably :)
> We were planning to fix it by collecting the underlying exception and
> rethrow it to the main thread, or optionally
interesting,
Hibernate Search is affected by this, but I thought the current
problem was due to the fact that work is being executed in another
thread.
We were planning to fix it by collecting the underlying exception and
rethrow it to the main thread, or optionally have it logged in case of
async
Hello,
if a transaction synchronization throws an exception, is it only logged, and
not thrown further (see org.hibernate.transaction.JDBCTransaction, line 273).
Is there some reason for this?
As Envers uses tx synchronizations quite extensively, when an exception is
thrown in the synchronizat
13 matches
Mail list logo
