[Mulgara-general] Transactions

[Alex Hall]

On 6/1/2010 7:15 PM, David wrote:
> Alex Hall <alexhall at revelytix.com> writes:
>   
> 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.
>>     
> No, this is _not_ what I want.  I'm trying to protect against the
> case where a "parallel" transaction has asserted inconsistent
> information.
>
> Transaction A reads the database, sees that there is no statement
> :Joe :dateOfBirth ?dob
> and asserts
> :Joe :dateOfBirth "Jan-01-2000"^^xsd:date
>
> At more or less the same time, Transaction B reads the database, also sees
> that there is no statement
> :Joe :dateOfBirth ?dob
> and asserts
> :Joe :dateOfBirth "Dec-31-1999"^^xsd:date
>
> I want whichever of these transactions is executed by Mulgara second to
> detect that its precondition (no preexisting statement :Joe :dateOfBirth
> ?dob) no longer holds, and FAIL.
>   

OK, I misunderstood the original question.  It's a bit of a hack, but
one possibility would be to use a SPARQL Update operation that will
conditionally modify the graph only if the precondition still holds:

INSERT { :Joe :dateOfBirth "Jan-01-2000"^^xsd:date }
WHERE { OPTIONAL { :Joe :dateOfBirth ?dob } FILTER (!BOUND(?dob)) }

The query as it is written might not work, but the general idea is that
the insert only occurs if the WHERE returns results.  The write won't
fail as far as the client can see, but it will be a no-op.  This is one
way of making writes dependent on reads, however crude it might be.

> To accomplish this, I need to send a transaction packet that coordinates
> re-establishing the precondition and executing the delta.
>   

The problem as I see it, and I think you understand this, is that even
if you implement some sort of transactional locking mechanism, there's
nothing fundamentally wrong from an RDF standpoint with having a single
resource with multiple values of the dateOfBirth property.  So
re-establishing the precondition is going to involve some sort of
application logic, OWL inference, etc.

One alternative to validating the precondition (that there is no date of
birth) before the write is validating the postcondition (that there is
no more than one dateOfBirth) after the write and rolling back the
transaction if there are any validation errors.  This could be done in
Mulgara with Krule, which supports validation rules that will raise
exceptions if they fail.  So the general approach would be start
transaction, insert statement, apply rules, commit transaction.  Krule
might not be well-suited in this application because it does not apply
rules incrementally, only to the whole graph, but it's a start.

The problem with expressing your application constraints in OWL or some
other rule language is that while the semantics of these constraints is
standard, the implementation of them is far from it.  Some services
might only raise warnings instead of exceptions, while others might not
let you apply the rules in the same transaction, etc. etc.  But it's one
approach worth looking into.

Regards,
Alex