> Let's close 1084. That's about i TIM good enough - it is.
>
> Experimentation on better TIM is good and might result in some more JIRA;
> first step is the experimentation and maybe looking at what other
> datastructures are candidates.
>
> If it's "copy on first write, then update in place (= same W transaction,
> same thread)" no locking is needed. Which is good.
Cool. That's definitely the direction I am trying ("mutate-in-place" strictly
within a snapshot-isolated transaction, which for Jena, for now, means inside
the thread). I am looking hard for the datastructure to support this well. The
current contender is the CTrie of Prokopec, Bronson, Bagwell and Odersky [1,2],
with O(log n) costs for the mutations and O(1) cost for a snapshot. As Jena
gets past the "one transaction per thread at a time, no sharing transactions
between threads" mode, I think the costs of concurrency will be worthwhile. But
maybe I am being too "blue-sky" there... In any event, I am trying to
understand if it is possible to introduce low-cost mutate-in-place operations
if we can make the assumptions about concurrency that we know we can make for
our case.
[1] http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf
[2] http://lamp.epfl.ch/~prokopec/ctries-snapshot.pdf [Here they introduce the
snapshot operation]
---
A. Soroka
The University of Virginia Library
