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 synchronization, I roll back the transaction manually. So, no data is persisted (which is the desired behavior), but the client isn't notified in any way that something went wrong; for the client, the operation behaves as if the tx commited successfully.
I suspect that maybe some applications rely on the fact that the exception is eaten and not re-thrown. If there are no contra-arguments to throw the exceptions, maybe a good solution would be to re-throw the exception is the transaction is already marked for rollback? Or if it was marked for rollback in the synchronization?
The related JIRA issues are:
By the way, how does Hibernate Search deal with such situations? I looked at PostTransactionWorkQueueSynchronization, and it seems that it's possible that the transaction commits, but the data isn't indexed properly, if the queueingProcessor.performWorks throws an exception?
I am ready to start working on changes for 3.6. That means I need to
branch off 3.5 work. Anyone not ready for that (obviously once svn is
Steve Ebersole <steve(a)hibernate.org>
I've shared some thoughts on HSEARCH-515 on the issue comments, I
definitely need to ask you some opinion about it.
I'll be able to implement one of the proposed solutions this weekend,
this week and next one I'm locked in a bank with bad connectivity,
so sorry communication can't be much better than some emails or JIRA comments.
I'd also love to hear your opinion on HSEARCH-512: the issue is caused
by an entity loaded in a Session which is cleared, the detached entity
passed to another thread and associated to a new session using
session.buildLockRequest( LockOptions.NONE ).lock( entity );
Seems possible there's an issue with the new core 3.5.x lock() method,
or even on the session.clear() ?
If the Session.clear() could have a bug, this could explain the
performance issues reported on the other threads/issues, as the batch
operations seems to slowly slow down, looks like a leak could be
Got busy and forgot to send this yesterday.
Attached is the log.
We discussed merging modules again to make sure we were all in
agreement. In consensus hibernate-annotations will get consumed into
hibernate-core. hibernate-entitymanager will not, it will remain a
We discussed test plans for Hudson. Strong will attempt to set up what
we spec'ed this week.
Steve Ebersole <steve(a)hibernate.org>
I recently thought about adding a constraint @NoNullElements to Hibernate
Validator. It would apply to iterables/arrays/maps and would ensure, well,
that the annotated collection contains no nulls.
There is a method noNullElements() in Commons Lang's Validator class, which
I find useful quite often. OTOH this comes at the cost of doing an iteration
over the collection, so people could refrain from using it and check each
element for null themselves when iterating.
I also thought about adding some flag to the existing @NotEmpty constraint,
which could enable this check. But @NotEmpty also applies to strings, for
which such flag would not make sense very much.
Any ideas on that?
On 04/21/2010 10:55 AM, Daniel Kavanagh wrote:
> Below I've attached the failure list, the test results aren't too bad from
> what i can tell.
> 26 errors, 7 failures.
> I'm not sure if that would be considered a good result or not?
I think that 0 errors and 0 failures would be better :-)
> If I find a problem for example where some data-type in a test is not
> supported by solidDB can we exclude that test from being run for that
There are certainly tests which doesn't applies for all databases. Most
of them uses a method like "appliesTo(Dialect dialect)", like
org.hibernate.test.rowid.RowIdTest . There are also plans to use
@SkipForDialect and @RequiresDialect , but I'm not sure what's the
current plans for that.
But note that changing the tests may not be possible, specially if the
dialect won't ship with Hibernate. In this case, you may want to
document those "known issues" and waive them.
> If I find an issue that would require a change to the hibernate core how
> would I go about having a fix implemented?
If it's a bug in Hibernate, just open a JIRA with the test case and
someone will look/fix.
> Finally, is there a location on the hibernate site where I can find the
> test results for other DBs? e.g. DB2.
Not yet. But running the testsuite against "hsqldb" is a good starting
point, as it usually passes 100% (no errors nor failures).
as that jdbc4 issue has been resolved, so i don't know if there is any specific reason that we cant apply this :
--- parent/pom.xml (revision 19221)
+++ parent/pom.xml (working copy)
@@ -132,7 +132,7 @@
<!-- require JDK 1.5 to run the build -->
<!-- we need at least Maven 2.0.8 because of a bug fix affecting our antlr usage -->
Strong Liu <stliu at redhat.com>