Exceptions thrown in a tx synchronization are eaten
by Adam Warski
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 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:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3543
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4721
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?
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
14 years, 4 months
Project layout
by Steve Ebersole
On the branch using Gradle for builds I started working on folding together hibernate-core, hibernate-testing and hibernate-testsuite. Gradle makes this very flexible and without further considerations I would simply define a total of 4 sourceSets in the hibernate-core project:
1) src/main
2) src/test
3) src/testing
4) src/intgTest
Gradle would let me define the compilation output directory for each sourceSet and we'd be on our way.
But of course we want this easily workable in IDEs. IntelliJ for example would not like the fact that we would need to define a total of 4 different compilation output directories for a single project (what IntelliJ calls module). So we need to find the balance that works best in command line as well as IntelliJ and Eclipse.
I've put together a few proposals based on knowing what will work in IntelliJ and talking to Max and Hans.
1) As far as we can tell the above would actually work. In IntelliJ we'd split the project into 2 modules. There was some drawback to this in Eclipse as well though the details escape me atm (max?).
2) Only fold hibernate-testsuite back into hibernate-core and leave hibernate-testing separate. This creates a semi-circular dependency but Gradle and IntelliJ can deal with it because the nature of the deps is limited in such a way that hibernate-testing would depend on classes from hibernate-core and hibernate-core would depend on hibernate-testing for it's test-classes. No clue if this would work in Eclipse.
3) Another thing to consider is whether hibernate-testing still needs to be deployed on it's own. We did this as a convenience so that users could use it in their own project tests. To be honest I have no idea how much use it gets in that way. If the answer here is no then the problem becomes a little simpler in that we could just compile the hibernate-testing classes would just be part of hibernate-core/src/test/java and would get compiled along with the test classes into test-classes. Gradle itself has this set up so we have a template we could easily follow for this approach. Worst case we could use this approach and still build the additional hibernate-testing jar for upload using include/exclude definitions to get the correct classes into the jar.
All things considered I think I prefer (2) or (3) as the solution to implement. One concern I had with them that I need to verify works is compiling unit tests and intg tests into the same output directory and whether separate test tasks could really work there. Also I need to decide whether that really matters.
Thoughts?
-- Sent from my Palm Pre
steve(a)hibernate.org
http://hibernate.org
14 years, 4 months
Default entity's data access
by Dmitry Geraskov
Hi, guys,
who could tell me what a default data access should be used in case of
entity mapping through orm.xml (field/property)?
Is it written anywhere?
I ask because there is seems a bug in hibernate - it use "property"
access by default.
Dmitry Geraskov.
14 years, 4 months
New version of HSQLDialect.java
by Fred Toussi
I have made changes and additions to HSQLDialect to work with HSQLDB v.
2.0.x. The Hibernate unit tests now run well with HSQLDB 1.8.x and
2.0.x.
New snapshot jars of HSQLDB v. 2.0.1 (for jdk 1.5 or 1.6) are available
here: http://hsqldb.org/support/ and should be used in tests. These
reflect the HSQLDB SVN /base/trunk/ (see SourceForge project pages) The
GA 2.0.0 showed a few issues that have now been fixed.
Version 2.0.x is transactional and has been written to the SQL Standard
(but relaxes some requirements by default). Therefore, the dialect
distinguishes between 1.8.x and 2.0.x versions and treats them
differently.
I am hoping that any remaining issue with HSQLDialect are identified and
fixed now. So please check the dialect and let me know if you have any
recommendations.
Some Details:
The following connection URL's can be used:
"jdbc:hsqldb:mem:db;hsqldb.tx=mvcc;get_column_name=false" or with
"hsqldb.tx=locks" (mvcc or lock based transaction management). The
"get_column_name=false" causes the JDBC driver to return the column
labels when getColumnName() is used on ResultSetMetaData.
There are 4 test failures with 2.0.x. The one below is caused by HSQLDB.
In JDBC PreparedStatement, it does not allow a locator on an existing
database lob to be used as the source of an assignment to the database.
testBlobClob(org.hibernate.test.legacy.SQLFunctionsTest)
I don't know the cause of the other failures.
Tests were performed with the latest Hibernate SVN code.
HSQLDB 2.0.x supports 3 URL properties to enforce strict type and name
checking according to ANSI SQL. The defaults for some of these are
relaxed. See http://hsqldb.org/doc/2.0/guide/dbproperties-chapt.html
Fred Toussi
HSQLDB Project
14 years, 4 months
Commit messages
by Emmanuel Bernard
Hi committers,
Please make sure to:
- always commit with a message
- always associate an issue number at the beginning of the message (unless you do style fixing)
- always associate a readable message to the issue number that explain what is going on
It makes reading logs and follow what has change much easier.
Bad:
""
"stuff"
"HHH-1234"
"oops"
Good:
"style and import fixes in engine package"
"HHH-1234 Fix incompatibility with merge and nested collections"
Even Better:
"HHH-1234 Fix incompatibility with merge and nested collections
Collections at the second level used to be ignored (ie not copied over) when merge was used"
14 years, 4 months
Default entity's data access
by Dmitry Geraskov
Hi, guys,
who coud tell me what a default data access should be used in case of
entity mapping through orm.xml (field/property)?
Is it written anywhere?
I ask because there is seems a bug in hibernate - it use "property"
access by default.
Dmitry Geraskov.
14 years, 5 months
Test failure on trunk
by Julien HENRY
Hi,
I would like to contribute to Hibernate. I have retrieved source code and started a full build. There are 2 test failures. Is it related to my configuration?
-------------------------------------------------------------------------------
Test set: org.hibernate.test.hql.BulkManipulationTest
-------------------------------------------------------------------------------
Tests run: 38, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 238.592 sec <<< FAILURE!
testSimpleDeleteOnAnimal(org.hibernate.test.hql.BulkManipulationTest) Time elapsed: 4.296 sec <<< FAILURE!
junit.framework.AssertionFailedError: incorrect delete count expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.hibernate.test.hql.BulkManipulationTest.testSimpleDeleteOnAnimal(BulkManipulationTest.java:938)
testDeleteUnionSubclassAbstractRoot(org.hibernate.test.hql.BulkManipulationTest) Time elapsed: 4.24 sec <<< FAILURE!
junit.framework.AssertionFailedError: incorrect update count expected:<3> but was:<1>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.hibernate.test.hql.BulkManipulationTest.testDeleteUnionSubclassAbstractRoot(BulkManipulationTest.java:1026)
[...]
Tests run: 2069, Failures: 2, Errors: 0, Skipped: 0
Thanks
Julien
14 years, 5 months
Fun with DDLWithoutCallbackTest
by Emmanuel Bernard
There are two things at stake here.
DDLWithoutCallbackTest was initially designed to check that the event listener validation is ignored. Hence the catch (javax.validation.ConstraintViolationException) {fail();}
What I forgot is that the test my still fails due to a database constraint error :)
Steve has fixed that by guarding against dialects not supporting column checks and also tests that a DB failure happens (which is an additional use case this test did not cover).
Another problem is that the BV integration does push some constraints (min / max atm) as column level check constraints which are not supported by all dialects. We cannot depend on the dialect because all that is set at configuration time and we know the current limitation on that. I'm perfectly happy with the DDL change not being propagated for min/max for these kind of databases (they are minor - HSQLDB, JDataStore, TimesTen).
Emmanuel
On 16 juin 2010, at 18:05, Steve Ebersole wrote:
>> 2.3) There is a general issue with
>> org.hibernate.test.annotations.beanvalidation.DDLWithoutCallbackTest
>> that I pinged you and Emmanuel about before but never heard a response.
>> Basically right now the test is totally geared to hsqldb. It even
>> failed initially on h2. The issue has to do with the
>> getDialect().supportsColumnCheck() protections I added. The issue is a
>> mismatch between how the mapping package handles check constraints and
>> how the validation code is handling them. IIRC the validation code is
>> always adding them to the Column. However the mapping package also
>> accounts for table-level check constraints. However, Table only applies
>> the check contraint at the level it was defined; basically it assumes
>> the code building it will put it in the right place (column level versus
>> tabale level) for the given dialect. So either we need to change the
>> way y'all push the check constraints to be dialect aware, or we need to
>> change the create/alter scripts for table to account for this new
>> requirement (although that of course changes the behavior).
14 years, 5 months
