JCR Sessions.

4 09 2006

I had thought with the structure of JCR that it would be a good ideal to open and attach one session to each request thread, avoiding the session creation mechanism. Before you think that this is totally daft, remember that the JCR persistence manager in Jackrabbit manages persistence for the entire JVM. So a managed session attached to the request thread is not so dumb…. well, perhaps, except that if anything goes wrong with the session, that state persists with the session to the next request. The interesting bit is that the error hangs around until and eden GC collection cycle takes place…. at which point any objects that were left uncommitted in in the session are finalized. If the finalization ‘rollsback’ the JCR object transaction, the session recovers, but a it looks like everything that was ‘committed’ after the error state is also rolled back.

In retrospect, creating sessions per request is going to be a better approach. However, its going to need some sort of hook into the request cycle to ensure that the Session is created and destroyed. Lazy construction is ok, but there is no unbind hook at the component level.

Advertisements

Actions

Information

2 responses

6 12 2006
MartinZdila

spring + jcr? (OpenSessionInViewFilter)

6 12 2006
Ian Boston

OpenSessionInViewFilter is Hibernate, the Session I am talking about here is the JCR session, not the Hibernate session.

but

Yes… proxies work with spring provided you can get a proxy cut at the right level.

unfortunaltely in Sakai we want this to be at the start of the request cycle, or on first use, and the session to end when the request is ended, not just when it comes out of service.

So there needs to be a top level request filter that unbinds things that have been lazy bound. The top level request filter exists but the unbind hook does not.

But a goog point none the less (or did I miss the point ?)




%d bloggers like this: