[Mulgara-dev] Requesting feedback regarding transaction semantics.

Andrae Muys andrae at netymon.com
Fri Oct 6 13:44:54 UTC 2006


I just finished putting a whole lot more semantics and design  
discussion on http://mulgara.org/confluence/display/dev/Transaction 
+Architecture.  In the course of which it occurred to me that I had  
an unanswered question regarding transaction semantics.

The issue is to do with the extent of Answer validity in the presence  
of subqueries.

In the case where you have a query containing a subquery you receive  
a single answer

OuterAnswer

at least one column of which contains a subquery.  Therefore a call  
to getObject on that column will return another Answer object

InnerAnswer1

A subsequent call to next() followed by a call to getObject will  
return a third Answer object

InnerAnswer2

And so on.

These Answer's *will* share the same transaction, and will remain  
valid *precisely* as long as the transaction remains open.

The question is when to close the transaction.

Option 1.
  - When the last Answer is closed.
Pros: Simple semantics, easy to understand, easy to document.  A call  
to an Answer can only fail if it has been explicitly closed.
Cons: *All* answer objects must be explicitly closed before any  
resources attached to the OuterAnswer are released.  This could be as  
high as N*M (where N is the nesting level of subqueries in the query,  
and M is the number of calls to next())

Option 2.
  - When the outer Answer is closed.
Pros: Only *one* call to definitively release all resources attached  
to the query.
Cons: Any subsequent calls to InnerAnswer's will fail with an exception.

Option 3.
  - Close all InnerAnswer's upon a call to next by an enclosing Answer.
Pros: At most N calls required to release resources (where N is the  
number of levels of subquery in the query).
Cons: Awkward to implement.  Not that much better than Option 1.

Personally I don't like Option 3.  However I'm undecided about 1 vs.  
2.  At this stage I'm leaning towards option 2 - it's more resilient  
in the face of client bugs.  Still it's a pure API design decision  
and option 1 is strictly more flexible.

I therefore would like people to consider their applications and  
comment.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd





More information about the Mulgara-dev mailing list