[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