I just realized that we don't have any distinction between read and write transactions at the graph level. Perhaps we should add that in V3.
For V2 the transaction must imply a write lock and my example above can not be done at the graph level. It can be executed at a level that provides a view type graph. So do view level graphs support transactions? if so does the TransactionHandler.begin() start a write transaction? On Tue, Aug 12, 2014 at 9:18 AM, Andy Seaborne <[email protected]> wrote: > On 12/08/14 08:58, Claude Warren wrote: > >> On Mon, Aug 11, 2014 at 6:19 PM, Andy Seaborne <[email protected]> wrote: >> >> >>> >>> Transactions: >>> >>> The text around transactions does not distinguish being inside or outside >>> a transaction. >>> >>> There are 2 base kinds of graphs - ones in datasets (views) and >>> standalone >>> ones, then things like InfGraph and other added functionality. >>> Transactions >>> on view graphs need to be defined in the context of the dataset because >>> transactions are connected. >>> >>> >>> > The point here is that several graphs may be in one transaction but other > graphs (other datasets) may not. > > > Using databases as a transaction example. There are multiple types of >> transactions -- I don't know if we want to get into supporting or >> identifying the type of transaction supported by a graph, but... >> In the current case (Jena 2.12.x) whith 2 threads T1 and T2. >> >> T1 begins a write transaction >> T1 add to graph >> >> T2 begins a read transaction (is this possible -- I think so) >> Can T2 find the triples written by T1 (note that the transaction is not >> yet >> committed)? >> > > No > > > T1 commits the transaction >> Can T2 now find the triples written by T1? >> > > No > > The isolation level in TDB transactions is serializable, not read > committed. TDB transaction are not lock based nor do they ever cause > system aborts due to unresolvable contention [*]. > > T2's view of the database is all commits up until then (so not T1) and > does not change. That would be read committed. > > > >> T2 ends transaction (just for completeness) >> > > And if T3 starts, it sees T1 updates and T2 still does not. see them. > > Given the nature of storing triples/quads and not entities (meaningful > rows in the data abstraction which is what SQL tends to do), the lower > isolation levels can have rather strange effects. And phantom reads are > horrendous. > > Andy > > PS 4.2 does not differentiate between inside and outside the transaction > so the isolation level is not relevant. > > [*] That would change if we have begin() with no read/write indicator at > the point of transaction promotion from read to write, an abort would be > possible if the DB is inconsistent with that happening. > > >> >> Claude >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
