Jeremy,
On 16/08/12 06:35, Jeremy Carroll wrote:
I am working on upgrading to TDB 0.9.2
An issue, (which may or may not be new) is that unlike GraphMem TDB will
throw a concurrent modification from a write that is concurrent with a
read.
If used non-transactionally. A good time for transactions ...
(The behavior I am expecting is for reads only to throw concurrent
modifications).
I am currently modifying DatasetControlMRSW (my current version
attached), using a copy of the source.
I am wondering if there is, or could be, some extension point where I
can add a factory for DatasetControl.
(Note the code to show extended stack traces showing both stack traces
where there are conflicting reads and writes).
The actual policy I am using is:
(Single Writer or Multiple Readers) and Multiple Optimistic Readers -
that recover from concurrent modifications.
Jeremy
Could you give some background as to what you are trying to achieve?
TDB transactions give a single writer AND multiple readers with full
isolation. Given that TDB transactions are write-ahead logging, not
lock based, all the lower levels like "read committed" (non-repeatable
reads) aren't much of an advantage.
DatasetControl is nowadays really only for internal consistency checking
and to give some compatibility for old-style (0.8.X) usage. Violation
of old-style MRSW
I don't know what multiple write support for RDF would look like -
locking to guarantee triple-consistency does not give any data model
consistency.
Andy
