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