[Mulgara-dev] Requesting feedback regarding transaction semantics.

[Life is hard, and then you die]

On Fri, Oct 06, 2006 at 11:52:27AM -0500, Paul Gearon wrote:
> Option 2 for sure.  It is more efficient, and more intuitive.   
> Besides, asking programmers to remember to close EVERY Answer when  
> they're done with it is just asking for something to be forgotten.
> 
> As for the "con" of failing on reading a sub Answer after the outer  
> Answer is closed: that is completely intuitive to me.  Besides, it  
> immediately tells the programmer that they got something wrong.   
> Sounds like a pro to me.

I concur. Option 2 sounds safer and less tedious, and I don't think
the idea of having children outliving the parent is useful.


  Cheers,

  Ronald


> On Oct 6, 2006, at 8:44 AM, Andrae Muys wrote:
> 
> >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
> >
> >
> >_______________________________________________
> >Mulgara-dev mailing list
> >Mulgara-dev at mulgara.org
> >http://mulgara.org/mailman/listinfo/mulgara-dev
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev