[PEAK] Re: Trellis-fork

[Sergey Schetinin]

I was thinking about how read invalidation would be processed. To
remind you what I mean by that, it's when there are concurrent
transactions and one has committed a write that makes some reads of
the still running one invalid. That means that transaction has to be
rolled back so that it has no invalid reads and restart from there. If
the read happened in a rule it can be safely rolled back and retried,
there are two cases when retry is problematic -- top-level @modifier
and @task.

If the invalidated read happened in @modifier, it can be retried as
well if we remember its arguments. It however requires that modifier
not to have any effects. It's a reasonable demand.

@task is a different matter -- it kinda runs as a modifier, but the
body of it is <generator>.next() which cannot be retried -- the
generator changes internal state irreversibly. To make things worse
@tasks would normally have effects, such as sending data over network.
This is unfortunate, but I think there's a way around -- @tasks would
need to have two modes which they could switch between by yield
TxnMode / yield EffectMode. In effect mode they would not be able to
read transactional data, just like things called from effect() queue
-- that ensures that @task effects will not be invalidated and will
not need to roll back. The transactional mode however would need to be
able to handle retries due to invalidated reads, something like this:

yield TxnMode
while True:
    self.a += 1
    # if self.a was changed after we read it but before we committed
    # we'll need to retry
    if (yield Commit):
        break

That's ugly and I really don't want to do that, so I'm looking into
possibility of some limitations to what and how could be used from
@tasks that would guarantee their reads won't ever get invalidated.


-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter