[Mulgara-dev] New transaction architecture review.

Andrae Muys andrae at netymon.com
Tue Oct 17 22:50:42 UTC 2006


On 18/10/2006, at 1:06 AM, David Moll wrote:

> I'm reading the Transaction Architecture - Development page (http:// 
> mulgara.org/confluence/display/dev/Transaction+Architecture), and I  
> have a quick question.
>
> Right at the beginning, there is the description:
>
> "The current transaction is maintained in the variable  
> DatabaseSession::transaction. If transaction is null, then there is  
> no existing transaction. Consequently an attempt to perform an  
> operation that requires starting a new transaction (ie. another  
> query), then the previous transaction is ended. Any associated  
> Answer's are supposed to be closed, the call to close(), in  
> endPreviousQueryTransaction() has been commented out to allow  
> server-side JRDF to continue to work - see http://mulgara.org/jira/ 
> browse/MGR-19."
>
> I'm following this (and the rest of the page) fairly well, except for:
>
> Consequently an attempt to perform an operation that requires  
> starting a new transaction (ie. another query), then the previous  
> transaction is ended.
>
> Is this saying that any attempt to perform an operation which  
> starts a new transaction will immediately end the previous  
> transaction?  To continue along that line of thought, it appears  
> that each user is given a Session, and each session can have  
> multiple transactions, with each transaction having its own  
> thread.  Thus, a Session can spawn multiple transactions, but only  
> one transaction may be "active" (either from begin or resume) at  
> any time.  From the above, does starting a new transaction require  
> that the previous active transaction for a given session be closed  
> or suspended?  It is not immediately clear to me from the  
> Confluence page.

I believe your confusion arises from over estimating the capabilities  
of the current architecture.  At the moment each session supports *at  
most* one transaction.  Therefore before starting a new transaction  
any existing transaction is ended.  At the moment if you want  
multiple overlapping transactions you need to use multiple concurrent  
sessions.  The primary target of this new architecture is to allow  
multiple overlapping transactions in a single session.

This however has proved to be a much bigger constraint on developers  
than we had envisaged.  We really didn't expect it to be all that big  
a deal.  What we didn't anticipate was the way RDF based applications  
almost universally desire this sort of access, and so it becomes a  
serious limitation users.

It is however important to note that this will not make Session  
reentrant (from the client).  Concurrent access to the session will  
be detected, and will throw an exception (and almost certainly  
rollback the transaction).

Andrae

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





More information about the Mulgara-dev mailing list