Yet ‘enforcing’ this kind of constraint in the gui, without using the locking catches many cases of constraint violation, which would otherwise only get caught by the database, rendering the session unusable.

There is only a small gap left, for another user entering the same value at almost the same time and the database constraint takes care of that.

The performance cost of this approach is very limited, since we only use a select on an indexed column and no locking.

So for us it was a nice compromise between performance, ease of implementation and usability.

I wanted to say that validating some type of constraints is not possible even conceptually in the application layer without locking tables that are involved in such validation. Consider unique key validation. The only way that guaranties uniqueness and would not throw a unique constraint violation is to do the following sequence of actions. 1. Lock the table from modifications 2. Query this table for duplicates of an incoming data. 3. If no duplicates found, insert incoming data. 4. Unlock the table or commit transaction. This is workable, but in my opinion cannot be a solution for concurrent multi-user enterprise level application.

Any other algorithm may render the assumptions of querying for duplicates invalid at the time of the insert.

If you want to go down this road I’d check the source code, write some tests and then propose a patch for the hibernate team to make it an official feature. This way you know (to some extend) it works, and it will get some support from the hibernate team and the community as well.

Regarding the constraints validation in the client, that is definitely the best approach when possible. However there are certain constraints that are more convenient to validate in DB or they perform better there, such as Unique Key, or complex business rules implemented in DB triggers.

I did some experimenting with the error handling and found out the session does not die after a SQL constraint exception (at least I could not make it die). If you handle exception and subsequently fix the data that caused the constraint to fail, everything works properly at the end. You can have multiple DML operations and fail only some of them, commit or rollback at the end (intentionally), etc.

So here is my idea about how to apply this to user interface. Trap every focus/selection change event that causes the underlying data context to change, and flush the session each time. Catch the error, display it (in a dialog) and do not allow changing the selection until the error is corrected (or the changes are rolled back). I successfully implemented a simple prototype that follows this approach. The biggest hurdle for me is to find proper events where to flush the session. (I am using SWT and it is not working as I would expect it.)

I absolutely recommend to validate all input against the constraints before flushing the session. In the project on which this article is based we basically used a NakedObject appraoch (http://en.wikipedia.org/wiki/Naked_objects) although we didn’t know it at that time. So we actually used the constraints as defined in the hibernate mapping to create checks/special UI control in the UI layer. So for Foreign Keys one only could choose by picking from a list, other values where checked using hibernate validation.

If everything fails and you actually get a sql exception due to a constraint violation the session is dead, which sucks, but is seldom.

An alternative approach is to edit data in special objects and then copy the content of those objects into the session objects. This results in much shorter session live time (which probably is a good thing), and of course you could recover more easily after an exception. But you need to create a seperate set of objects (possibly classes), which makes life even more complecated then it is already. …

As a German saying goes: You have to die one death

Here is my concern: how to handle database errors/constraint violations. The scenario is as follows. User changes several records in a grid or in different parts of one form (frame). When user saves the changes, hibernate flushes all changes to the database. Some of the changes are successful and some of them fail DB constraints. Ideally, you would want to navigate to the UI element that caused the constraint failure, and give the user a chance to fix the error, while preserving the valid changes.

Here is an excerpt from Hibernate documentation: “If the Session throws an exception (including any SQLException), you should immediately rollback the database transaction, call Session.close() and discard the Session instance. Certain methods of Session will not leave the session in a consistent state. No exception thrown by Hibernate can be treated as recoverable. Ensure that the Session will be closed by calling close() in a finally block.”

If there are multiple failures, it gets even more complicated.

Your thoughts on the error handling subject would be much appreciated.

Of course rich client applications have a lot of other problems like this:
- Database connection needs to get through firewalls
- The database connection can be easily broken over the Internet (we use PostgreSQL and have to implement reconnection functionality because the connection so often get lost on long distance sessions)

I really like rich clients but the ORM frameworks most often simply don’t consider the extra needs of these kinds of apps which makes them hard to develop.

We also opted for the one Session for one Frame approach (or something very similar).

In the worse case you can just create your DAO objects with the long-lived session object directly and maintain the session object in your editor state somewhere. Then just ensure that all other DAOs that are called use that same session by initializing them with it as well. This approach is harder but also doable.

The only other way is to do the second approach via code instead of a container which makes configuration more laborious but is what many RCPs have done over the years.

Supposedly the new JSR 299 (or something like that) will address conversational scope and should apply to RCPs.