I examined the Transactional interface more carefully, and the comment on end()
reads "/** Finish the transaction - if a write transaction and commit() has not
been called, then abort */“.
So it seems that there are definitely multiple ideas about the meaning of
end()! {grin}
---
A. Soroka
The University of Virginia Library
> On Sep 25, 2015, at 11:43 AM, Andy Seaborne <[email protected]> wrote:
>
> 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.
>>
>
