Hibernate version:
2.1.6

Name and version of the database you are using:
DB2 8.1

I've read all the doc that I can find and am still a bit confused about handling (or not) database exceptions in my Swing/HBN app, which uses potentially long-running sessions.

If an end-user tries to add a row that violates a DB unique index, then saves, an exception gets thrown. The doc is very clear that, if an exception is thrown, I have to tx.rollback() and immediately close the session. I know this is true, because if I fail to do this, I get odd "null id in entry" exceptions from HBN the next time I flush(). The session just gets all mucked up. Some doc says that I should just go ahead and stop my app altogether if a database exception occurs. This seems extreme.

I have written code that catches the exception, does the rollback, closes the session, creates a new session, and reassociates all of my now transient instances w/ a newsession.load(). It seems to work OK, but I wonder if the reassociation bit is meant more for managed, multi-layer environments where detachment is by design. Am I not seeing something?

Is it simply up to my *client* code to sense that a unique contraint has been violated and not let the tx.commit() occur until its fixed?

Any thoughts/help appreciated.

AJ

Of course...

That seems like the database's job....Its a whole lot better at stuff like that than I am...

So I guess this means I override equals() and hashcode() on the class of the items held in my set, preventing dups right at the source?

aj

A lot of things are "the database' job", but these days its cool to duplicate everything in Java. The first layer of constraint validation has in fact always been in the application tier in a two-tiered system with non-dumb terminals. Welcome to the world of client/server programming.