Yes - in particular, multiple indepentent components, possible distributed.

One case is deep integration of TDB and Lucene.

Or two datasets.

Another is distributed components.

... in principle.

        Andy

On 26/05/17 16:59, dandh988 wrote:
By XA transactions are you referring to two phase commits aka X/Open and DTC 
frameworks?
Dick
-------- Original message --------From: Andy Seaborne <[email protected]> Date: 
26/05/2017  14:19  (GMT+00:00) To: [email protected] Subject: Re: Transactional 
abort() on READ.
By the way, with the new transaction engine, these details get handle by
the framework.

https://github.com/afs/mantis/blob/master/dboe-transaction/src/main/java/org/seaborne/dboe/transaction/txn/Transaction.java#L180

In theory, this will support XA transactions as well. "in theiory" means
the design has the necessary features, but it hasn't been tested out.

      Andy

On 26/05/17 13:34, Andy Seaborne wrote:


On 26/05/17 11:49, Dick Murray wrote:
I've got some transactional code and I noticed that when Txn.executeRead
caught an Exception it calls abort() then end() via a common onThrowable
method.

This caught me out because my (poor) code didn't expect abort() on a
READ,
which I've fixed.

Does Jena expect;

read -> end
read -> [abort] -> end
read -> abort | end

Bias from previous roles I was expecting read -> end and write ->
[commit |
abort ] -> end...

D.


The app can optionally call commit or abort on a READ transaction if it
wants to.

read -> [abort|commit] -> end

This may become more important when promotable transactions arrive -
reader flip to being the writer (if it is possible).  That's WIP - it
works and is tested, it is switched off currently pending thinking about
interface implications.

Read-only, enforced, is actually quite useful.

       Andy


Reply via email to