Ok. So Hibernate sends the SQL statements in a "random" time to the database. If you use flush(), it sends the statements when you want.

Using postgreSQL on windows, I HAVE TO work with transactions to have my data really inserted/updated/deleted. But if I use HSQLDB, it works fine just to call flush and close the sessions.

So what I'm trying to do is



I can see the SQL statements on my console, and they are right. But when I query the database, the record is not there. As I said before this only happens with postgreSQL. HSQLDB runs ok (I just tried with these two).

I do not want to code like this:



for the simple fact that there's no need to a transaction here.

Also, I may be calling this method from another class that's responsible for managing a transaction.

One example goes like this:
I have Users, Groups and Permissions.
Permissions can be assigned only to groups. To simulate an User having permissions, each User has an unique group for himself, wich has himself as the only User. So calls like addPermission(user, permission) are actually adding the permission to that special Group.

So I can call createGroup(group) that does something like the first lines of code I wrote above. But if I try to create an User, I must create the User and his special Group. So the transaction is being handled by another class wich calls createUser() and createGroup() in sequence and handles the transaction to asure that both classes are persisted.

Is this how hibernate must work or is this a bug with postgres. What should be the behavior of hibernate in this case?

I hope I made myself clear. If you guys can't understand what I mean. please tell so and I'll try to make myself clearer.

It is possible to supply your own connection to Hibernate, one with autocommit true. And then you will get what you want.


But this is a Bad Thing. Your system will be slower and transaction isolation will be compromised. You do not really want this. It has nothing to do with Hibernate, it is just about correct use of a database.

Sql won't be executed in the backend if u don't call session.flush(). Hibernate's some async way of sql execution is harmful to data reliability while good for performance. It doesn't keep the persistent journal of each transaction locally, so we'll encounter data loss in case of system crash or power failure. We are just under the delusion that objects are saved properly. Not for mission critical use.

What are you talking about?!


I think you are a bit confused about how transactions work. Perhaps seriously confused.

I did some test. Hibernate didn't execute sql at once after I called session.save(object). If must I call session.flush() every time I save something, then performance harmed, am I right ? ;-) I mean caching is evil sometimes.

I won't provide my own connection. I do not agree with that either. I just wanted to make sure I HAD to call beginTransaction/comit() for the changes to take place. I can't find anything on that in the manuals.

Actually by reading then, I understand that flush() would be enough.

You dont have to call session.flush() after every operation. flush() is simply a way to group some logical operations. In SQL-terms, think of this as somewhat akin to setting savepoints.

You seem to have some serious mis-understandings about transactions and jdbc in general. I highly suggest getting more familiar with these subjects. Just because you tell your database to update some particular row does not mean that your database immediately applies that change; in fact it will not apply changes until you issue a commit.

Hibernate has the ability to batch some sql operations using the jdbc batching capibilities. The more that can be batched up, the fewer times the jdbc driver actually has to talk to the database.

Thus

is perfectly valid. The insert and the update will not occur until you call flush(). The database will apply the requested changes once it is issued the commit command (either by Hibernate through the connection or as part of a larger JTA transaction). This is a beautiful thing.


and sometimes its just necessary. Transacted operations entail a need for some form of caching; how else would you suggest rollbacks happen? Would you complain to database vendors that they are not applying your changes immediately? Of course not.

check out http://www.hibernate.org/hib_docs/reference/html_single/#manipulating-data specifically sections 7.8 and 7.9

beginTransaction()/commit() are not explicitly needed because they are not used when using JTA transactions...

My point is. If I didn't call beginTransaction() it means I will loose my updates???

If I didn't call beginTransactin that's because I do not want a transacation, so autocommit would not be a good thing?

Maybe that's because u can call several updates before hibernate flushes them to de database, and u can't asure that every satatement will succeed?

Please, be patient with me :).

I think you said you are not using a transacted data source, correct? So yeah, you would have to call beginTransaction() prior to performing operations against the database or you would lose updates.

Now I understand how transactions work without digging them up in source code. Thanks !