[Mulgara-dev] adding ResolverFactoryInitializer.getSessionFactory()

Life is hard, and then you die ronald at innovation.ch
Mon May 19 06:50:16 UTC 2008


On Mon, May 19, 2008 at 11:36:40AM +1000, Andrae Muys wrote:
> 
> On 19/05/2008, at 11:02 AM, Life is hard, and then you die wrote:
> > 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.
[snip]
> >> 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.
> 
> The concern was due to an inability to provide many guarantees  
> regarding the relative state of the current Session and any Session  
> obtained in this way.  For the moment (absent XA2), the only  
> guarantee we can offer is that a Read-Only session obtained from  
> within the Read-Write session will reflect the state of the system  
> prior to the commencement of the Read-Write Session.  As you discuss  
> below, this is the only guarantee you are requiring, so in this case  
> you are fine.

Correct. No, I'm not asking for any guarantees other than the usual
(snapshot) isolation being provided anyway, i.e. this is _exactly_
like (and is in fact) two separate clients. The only thing required is
that we can indeed run a read-only transaction parallel to the current
write transaction without blocking, but you already gave us that :-) .

> >> 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?
> 
> Yes it does, immensely.  Granted this technique maybe invalidated  
> once we support multiple writers, so we will have to sit down and  
> really think about precisely what you are trying to achieve once the  
> XA2 transaction architecture is rolled out.  Specifically given the  
> partial-order semantics of transaction ordering under  
> serializability, there is no-longer any obvious answer to the  
> question "What was the state of the datastore 'prior' to this update"  
> --- and there is definitely no-longer a unique answer.  But that is a  
> problem for another time.  For the moment, given single-writer  
> semantics, what you are doing is fine.

I think the multi-writer stuff will be fine. The expectation is not
exactly that the db be completely in the state it was before the tx
started, but instead that the modifications in the current transaction
not be visible. It is ok to see mods made in another transaction after
the current one started, the reason being that if that other
transaction affected our queries then they would also have run both a
the query on a snapshot that didn't include those modifications and a
query afterwards, thereby capturing that change, and all we need to do
is capture the change after that.

Furthermore, because this is used for invalidating caches, we don't
care if we miss a quick double transition, e.g. a 0 value being set
to 1 and then reset to 0 very shortly aferwards - it just means we
avoided invalidating the cache.


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list