[Mulgara-general] Transactions

[Alex Hall]

On 6/1/2010 3:16 PM, David wrote:
> Thanks much for the prompt reply.
>
> Paul Gearon <gearon at ieee.org> writes:
>
>   
>> On Sun, May 30, 2010 at 5:09 PM, David <dsiegel at acm.org> wrote:
>>     
>   
>> Well, for the moment Mulgara does not do concurrent updates.
>>     
> I'm far more concerned about "logical" concurrency, and the effect on
> database consistency, than I am about write concurrency. Improving
> performance would be great, but consistency's a bedrock requirement.
>
> Say 2 processes, A and B, start at the same time, and each reads from
> Mulgara, and then based on what it read, prepares a transaction of
> inserts and deletes. Both send their transactions at the same time.
> Mulgara will serialize their execution, running either A then B,
> or B then A.
>
> Both transactions, though, are based on the same view of the database
> (they both did their reads from the same state of the database), and the
> transaction that Mulgara executes second has no direct way to ensure
> that the assumptions on which it was based, were not invalidated by the
> transaction that ran first (in my example, that the first transaction
> didn't write a "Joe dateOfBirth ?x" statement).
>
> So, without the kind of workaround I mentioned in my message, there
> seems to be no way to guarantee the consistency of the database.
>   

Because you're talking about logical consistency, I'm not convinced that
a transactional solution with locking is necessarily your best approach
here.  If your application expects certain invariants, such as
dateOfBirth being a functional property, then it's up to you to enforce
them.

Basically, what you're trying to do is describe a change to an RDF
graph, and communicate this change to the graph service.  If you're
concerned about logical consistency of the graph, then you need to
describe the change logically in a way that maintains that consistency. 
I've found the following paper to be extremely helpful in thinking about
applying modifications to graphs:

http://www.w3.org/DesignIssues/Diff

What you're looking for is essentially a strong delta -- a change
description that carries enough information to accomplish the desired
logical outcome regardless of the input graph.

Going back to the dateOfBirth example, the logical outcome you're trying
to accomplish isn't the insertion of a particular statement.  The
logical outcome is that Joe has exactly one birth date, with the given
value.  If he previously had a different one, then it needs to be
removed.  So your change can be expressed as a SPARQL Update request in
the form:

DELETE { :Joe :dateOfBirth ?dob } WHERE { :Joe :dateOfBirth ?dob };
INSERT DATA { :Joe :dateOfBirth "Jan-01-2000"^^xsd:date };

or whatever the appropriate XSD formatting is, without bothering to
look.  As long as this request is executed atomically as a single
transaction, it doesn't matter in what order multiple requests are
executed, you're guaranteed that it will result in a logically
consistent graph.  You don't have to do any transaction management on
the client end or locking of graphs; all that's required is that your
service supports wrapping multiple operations in a single transaction. 
I think you'll also find that such an approach is more portable and
better suited to a distributed environment.

While Mulgara doesn't currently implement SPARQL Update, the equivalent
operation, along with the requisite wrapping as a transaction, is most
certainly supported using the existing TQL service endpoint.

Regards,
Alex