[Mulgara-dev] adding ResolverFactoryInitializer.getSessionFactory()

[Life is hard, and then you die]

On Mon, May 19, 2008 at 10:46:03AM +1000, Andrae Muys wrote:
> 
> On 18/05/2008, at 3:26 PM, Life is hard, and then you die wrote:
> >
> > We have a resolver that works a bit like a trigger, and it (sometimes)
> > needs a separate Session (from whatever the "current" session is) to
> > run a query on. So far this has been using a bit of hack to get the
> > SessionFactory (namely by assuming LocalSessionFactory was being used
> > and exploiting the fact that the underlying SessionFactory is shared
> > between all LocalSessionFactory instances). However, this hack fails
> > now that we've switched to RMI, and it also fails for our embedded
> > mulgara usage where we don't use LocalSessionFactory either.
> >
> > There's currently no way (that I can see) for a resolver to get a
> > handle on the "current" SessionFactory (the one it belongs to); so I'm
> > thinking of adding a getSessionFactory() to the
> > ResolverFactoryInitializer to get that functionality - does anybody
> > have any reservations or reasons not to do this? Or any better
> > suggestions?
> 
> I have serious reservations regarding the correctness of such an  
> operation.  The reason a resolver can't obtain a new session like  
> this is that, to the best of my knowledge, such a session cannot be  
> used without violating ACID guarantees.

I don't understand exactly why think ACID will be violated: the
session is a separate session, just like any other, and we run it in a
different thread, so it appears exactly like just another client.

> I would be very interested  in knowing why you feel you need this.

We have a "trigger" to do certain things when certain data changes. To
detect those changes we sometimes need to run a query, i.e. compare
the results of a query before and after the changes. Now we really
don't want to run those queries on every modification. So instead
we hook into the tx prepare phase (XAResource.prepare) and when we
detect that a modification in this transaction may have affected the
query results we go and run the query in a separate thread on a
separate session which, thanks to snapshot isolation, gives us the
results before the transaction was started, and we can then compare
those with the results from running the query after the current
transaction completes (and those post-completion queries are also run
from a separate thread, and hence need their own session).

Does this help?


  Cheers,

  Ronald