On 25/09/15 15:07, A. Soroka wrote:
Okay, I committed a pair of simple tests in commit() and abort() to
see to it that you can’t call them outside a transaction and that
made all of AbstractTestTransaction pass.
This worries me, because you suggested that it would probably require
a finer-grained lifecycle modeled, and I didn’t do that, so I’m
wondering what I’m missing. {grin}
It'll depend on the status of "end" -- I have considered the transaction
to run from begin() to end() and end() in a W transaction without
commit() or abort() is an error. c.f. R transaction of begin(R)-end()
scoping.
The idiom is then (and can be made nicer in Java8):
begin(W)
try {
... reads and writes ...
} finally { end() ; }
or variations with an auto-abort on exceptions. The try{} is a
consistency scope. That does not work with the auto-autocommit.
In your case begin(W)-end() is a silent abort?
BTW what happens if you get end-end? index().end(); is called
repeatedly. Does that matter? (haven't had time to look at that)
One remark of yours gives me
pause, though: “I managed to add after commit.” That’s definitely
intentional, because on your advice [*], I set up
DatasetGraphInMemory so that a mutating operation outside of a
transaction auto-wraps itself in a transaction. So calling add after
commit is actually two legitimate transactions “under-the-hood".
> Did I misinterpret what you advised? Did you mean me to add
> “auto-transact” in a more configurable way?
So in a multithreaded environment, the autocommit despite being inside
the begin-end is not consistent with the begin-commit part. Needs
thinking about.
A general point : we need to decide the fine grain details of the
transaction models (or variations) we want to provide. Until now it's
been TDB and DatasetGraphWithLock so not a wide range of choices pushing
the design boundaries and stuff is implicit. Great thing about 624 is
sorting that out.
Current TDB works non-transactionally until the first begin then
explicit transaction only. That's to maximise compatibility.
autocommit and disk is dire (disk I/O per quad add is going to easily
become painful - just look at many database lists with "why does my
simple app go so slow" questions)l in -memory is different.
TDB non-transactional isn't even an implicit transaction. Current TDB2
is explicit transaction only because (1) it has no concept of update
in-place due to immutable data structures and (2) I haven't spent any
time on it.
I like the Java8 style Txn.executeWrite style (maybe shorted names -
details).
In TDB2, transaction are promotable (read to write) though it is allowed
only if no W transaction has run (strictly, started) and started it's
own version of the DB. The API is more general that TDB2 supports.
begin() and auto-promote is possible but not IIRC done.
promote is the only time system aborts can happen so it creates
interesting app issues.
My inclination is to suggest that we encourage explicit transactions as
the recommended style. (Rhetorically) Is it to much of app burden?
Don't know. Thoughts?
Andy
--- A. Soroka The University of Virginia Library
[*] http://permalink.gmane.org/gmane.comp.apache.jena.devel/10529
On Sep 24, 2015, at 1:05 PM, Andy Seaborne <[email protected]>
wrote:
The rest are testing that e.g. begin-abort-commit is an error. It
looks like the transaction lifecycle is not being tracked. It
needs finer granularity than DatasetGraphInMemory.isInTransaction.
May be as simple as NOT_TXN -> ACTIVE_TXN -> FINISHING_TXN (->
NOT_TXN). Just in/out isn't enough for, e.g.
begin-commit-add_quad->end , begin-commit-commit. I managed to add
after commit.
