TDB2 recently got TransactionListener to tap into the transaction
lifecycle.That was for a specific need (for abort to undo some changes
made ahead of time) but the idea might be general.
In RDF Delta, there is DatasetGraphChanges whch enables you to get
changes, which includes begin-commit.
Tapping into the Transactional does seem like a good way to go though.
Andy
On 23/10/2019 15:31, ajs6f wrote:
Hi Dick!
I'm afraid the answer for TDB2 and TIM is no, not out of the box. Both use MVCC
techniques, not buffering operations. Andy can tell you about TDB1.
This might (maybe) be helpful:
https://github.com/apache/jena/commit/241060548a9fca777b7d40f1f216ae7ed930b20e
Before Andy and I got TIM into the design it now has (multiple MVCC indexes
connected transactionally) I did another design that _does_ use buffering of
operations. Since we didn't go with it, we cut it out of the codebase, but the
history is there if you find it useful.
Cool - might be a good starting point for buffering. I had a need for a
buffering dataset, which keeps the change, makes find() work as if the
change happened but does not pass add/delete through until requested.
ajs6f
On Oct 23, 2019, at 5:58 AM, Dick Murray <[email protected]> wrote:
Hi.
Is it possible to natively detect whether a write has occurred to a
DatasetGraph since a particular epoch?
For the purposes of caching if I perform an expensive read from a
DatasetGraph knowing whether I need to invalidate the cache is very useful.
Does TDB or the Mem natively track if a write has occurred?
Currently I am wrapping the Transactional but am interested if this can be
shimmed to the underlying SPI.
Regards DickM
