Hi, here is my scenario. Points will be given fairly!

Simply, the question is, why in my configuration, does the session.save method call not obey transactions for transient objects?


here are the details:

I created a new transitive object (Parent), and this transient object has a one to many mapping to another object (Child).

Here are my mappings:
Parent:

<set name="children" inverse="true" cascade="all-delete-orphan">
<key column="parent_uid"/>
<one-to-many class="Child"/>
</set>

Child:

<many-to-one name="parent" class="Parent">
<column name="parent_uid" not-null="true"/>
</many-to-one>

Note the *not-null* attribute for child.

This is what I did in my java code.
try{
s = sessions.openSession();
t = s.beginTransaction();
Parent parent = new Parent();
Child child = new Child();
parent.addChild(child);
s.save(parent); <--- throws an exception.
t.commit(); <--- never executed
}catch(Exception e){
if(t!=null)
t.rollback(); <--- this gets executed.
}

Notice that the s.save(parent) line of code throws an exception because I did not call child.setParent(parent). The exception thrown looks like this:

org.hibernate.PropertyValueException: not-null property references a null or transient value: Child.parent

Again, my question is, why is the parent object saved into the DB even though the transaction was never committed, rather rolled back? It seems like session.save() does not obey transactions when saving transient objects!

I have verified that transactions do work correctly in other cases, such as when updating detached objects. It only doesn't work for new transient objects.

I am using a nonmanaged environment with JDBC, the hibernate properties file is as follows. Thanks in advance!



hibernate.properties:

hibernate.dialect = org.hibernate.dialect.MySQLMyISAMDialect
hibernate.connection.driver_class = com.mysql.jdbc.Driver
hibernate.connection.url = jdbc:mysql://localhost/SOMETABLE
hibernate.connection.username = SOMEUSER
hibernate.connection.password = SOMEPASSWORD
hibernate.c3p0.min_size=2
hibernate.c3p0.max_size=5
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statements=20
hibernate.show_sql=true
hibernate.transaction.factory_class=org.hibernate.transaction.JDBCTransactionFactory
hibernate.current_session_context_class=thread

I was able to answer my own question.

the solution was to set FlushMode.commit on my session.

Now, I am trying to figure out why transient-entity-saving does not obey transaction rules. This seems silly imo.

it's silly to rely on transactions on a db that doesn't support them ;)

(innodb tables is the key to do that in mysql)

ok, so if I had used a different db like innodb, then leaving FlushMode=AUTO would not have persisted the transient object to the database?

GAH!

I guess that means with InnoDB, my Session.save() would have made an 'insert' within an InnoDB transaction, and rolling back would have correctly rolled back the transaction.

Also, since I'm not using a transactional database, I might as well not use hibernate transactions, and just set FlushMode=COMMIT or NEVER and manually call Session.flush() whenever I am done with an "atomic unit" of work.

Is this correct?

Thanks in advance!

of course it would have persisted it to the database (otherwise queries in the same transaction wouldn't be able to see the data).

The issue is that rollback on non-innodb on mysql does not actually result in any rollback...why don't you just use transactions?

I've switched over to InnoDB.

tell me how queries will be able to return the valid results if your changes is not put in the database ? :)



congratulations ;)

well... I was *thought* that hibernate would do something intelligent with the queries, like for select queries, query both the backend DB (in my previous case, the MyIsamDB) and also run the query with the objects in session/transaction scope, and do a merge on both results... something *crazy* and *magical* like that. I guess Hibernate just can't handle that huh?

:)

nope, hibernate is not a database.