[
https://issues.apache.org/jira/browse/JENA-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818509#comment-13818509
]
Andy Seaborne commented on JENA-189:
------------------------------------
Have you looked at TDB? This note seems to be SDB-centric in expectations.
{quote}
As implemented Iterators require that if there is a change to the underlying
data store the iterator must fail. Thus any write cancels all reads.
{quote}
In TDB, Iterators from different transactions can exist at the same time and
continue to iterate. They do not throw exceptions or fail on change outside
the transaction - the changes simply aren't seen; writes do not cancel reads.
{quote}
The use of iterators block updates making the use of graphs in high frequency
read/write
environments difficult.
{quote}
In TDB, different versions of the database exist at the same time. Iterators
do not block later writers or commits.
{quote}
4. Serializable requests
within this isolation prohibit concurrent read/write, similar to the
current situation. Pro: absolute consistency. Cons: lower concurrency
{quote}
TDB is fully serializable and allows concurrency, including concurrency between
multiple versions of the database. TDB is not 2PL (SS2PL) based; it's MVCC
(multi-version currency control). (By "MVCC", I mean a path-copying immutable
datastructure style, not the multi-entry-version-id style - "MVCC" is used in
both contexts.)
Other:
Locking a subgraph does not stablize query results. Queries can involve
pattern negation (NOT EXISTS, MINUS). OPTIONALs also can depend on the absence
of triples. Read-repeatable would also need to track read-repeatable-no-result.
> Jena 3 / technical
> ------------------
>
> Key: JENA-189
> URL: https://issues.apache.org/jira/browse/JENA-189
> Project: Apache Jena
> Issue Type: Brainstorming
> Reporter: Andy Seaborne
> Attachments: IteratorLockandTransactionsinJena3.pdf
>
>
> This is a JIRA to discuss and collect technical changes to Jena that would
> warrant a "Jena3" whether an incompatible change or just sufficient changes
> to mean bumping the major version number is best.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
