transaction extensions for API

Sergey,

I've been having a think about your PersistentModel interface.  Generally,
I'm feeling pretty comfortable with it.  Here are a few comments and
questions.

1)  As you propose, Transactions seem to operate within a single model.  I
have multiple models in the same database, and its conceivable that an
application might want to do transactional updates across more than one
model.  I don't have an instance of that right now, but I would prefer not
to rule out the possibility.

Do you think there might be a way of achieving this?  One way would be to
pass in a transaction object on the update calls, but that seems a bit
tedious.  Alternatively, perhaps there could be a call to tell two models to
link there transactions.  Would have to be done before any transactions had
started though.  Models from incompatible implementations could just refuse.

2) Your description of the API suggests a particular implementation, i.e.
one where a persistent model has an in memory copy of incomplete updates and
a persistent backend.  I'm thinking it might be a bit of work I could avoid
doing finds and the like on a mixed implementation like that.  Being lazy,
I'd probably try to avoid keeping in memory copies and use the database
transaction mechanism directly to control the updates.

3) Could you clarify the expected semantics:

If a transaction is in progress, will calls that query the state of the
model reflect the incomplete updates.  Calls affected are elements(),
contains(), size(), find() and duplicate().

What happens when a call which creates a new model, such as find or
duplicate, is made on a model which has a transaction in progress i.e. if I
call find or duplicate on a model with a transaction in progress, do the
models returned share the same transaction as the original?  What happens if
checkpoint is called on either model?

What happens when an application which is unaware that the model it is
dealing with is persistent, calls say, add()?  As things stand the update
will never be committed or rolled back.  If there were a begin transaction
call, then calling add()outside a transaction could be regarded as an atomic
action and committed automatically.  This would preserve the semantics of
the model interface.

4)  In my current implementation, createModel causes an update of the
database.  Since  I have multiple models, I need to store state about them.
So for me, createModel is a call that would have transaction semantics.  How
would you envisage this might work?  Or is that my problem?

5)  I have similar issues with createResource, createLiteral and
createStatement.  Right now, these cause database updates in my
implementation.  I haven't finished thinking this through though, so I'm not
sure I'll stick with this approach.

I'm feeling pretty comfortable you are on a good line here.

regards
Brian

Received on Wednesday, 10 May 2000 16:23:17 UTC