I'm starting a new transaction when running a Query, but to prevent problems with loading Postgres blobs from the returned objects (a Postgres blob must be loaded within a transaction - see my previous post), I'm leaving the transaction open once I've returned the results to the calling method.

Unfortunately this leaves me with a couple of processes left running for each unfinished transaction, and a server that won't shutdown nicely.

Is there any way to force-load the properties of an object and get the transaction commited? Or maybe start a new transaction when each object's properties are lazily loaded (this would probably be OK - read consistency isn't a vital consideration). Or am I just going to have to set a low timeout on the connections?

You can force initialisation using Hibernate.initialize(). You can also reatatch the object to the session later on using session.lock(object, LockMode.NONE).

I think your real problem is correct transaction demarcation if I understand you correctly. If yes, this is really a code problem, you should take a look at some patterns like Open Session in View, and Servlet Filters (if in a web environment) or something like Springs Transaction demarcation (i will have to read into that sometimes)

Hmm. I don't probably don't want to force load the properties actually - that would suggest having the entire blob in memory, which I obviously want to avoid.

But yeah, the problem is basically where to demarcate the transaction. The application can run independently of a webapp, so I don't want to use any Servlet-based patterns. In fact I have my own simple transaction manager, and demarcate the transactions programmatically.

So I guess the best solution is for me to push the transaction start up a few layers. An alternative would be to somehow create a new transaction just for the blob read.

Still, I'd be happier if my transactions were more granular, but I can't see how I can keep the transaction used to read the blob open until such time as the blob has been finished with, without making the client responsible for closing the transaction.

The concept of an Interceptor is not restricted to a web-environment, although a Servlet filter is an implementation method for Interceptors. By writing an Interceptor you don't "move up the layers", but you simply listen to events in your application (in this case, generated in the presentation layer). It is just application infrastracture code, very much like an application server, which is also not considered to be in any of the traditional layers.

Check out Spring if you don't want to write it all yourself, but its actually very easy for the 90% non-special cases.

My apologies, I thought that both Open Session in View and Servlet Filters involved a servlet. USe of an Interceptor wasn't mentioned in this thread.

When I say "move up the layers", I'm talking about the architecture I have, which uses the HibernateSimpleTransactionManager I described here. Rather than just allocating a new session/transaction for each new incoming thread, I have greater control over when they are started. Also, those threads (in this case) are not, contrary to what you say, coming from the presentation layer; they are coming from the RMI layer. I don't have a presentation layer up unless I'm testing the user interface.

You've also assumed that I'm using an application server, although I'm not.

I don't assume anything, I just want to point out that "Interceptor" is a concept. It can be implemented with a Servlet filter, a WebWork Interceptor and it is actually the same pattern that the EJB programming model uses. Calls are intercepted to execute cross-cutting concerns, such as security and transaction demarcation. If you already have a design like this, you are halfway there anyway :)