[Mulgara-dev] Requesting feedback regarding transaction semantics.

Paul Gearon gearon at ieee.org
Fri Oct 6 16:52:27 UTC 2006


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.

Paul


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



More information about the Mulgara-dev mailing list