Hi Andy, thanks for this reply, I find it very useful. As you said, our documentation is not that clear and perhaps we should improve it with content from this email.
In particular, I think having in the documentation: Dataset dataset = ... ; is not really helping users. Need to go off-line for a bit, but I'll propose changes to the document: http://incubator.apache.org/jena/documentation/tdb/tdb_transactions.html If the problem is just in the documentation, it's much easier to fix. ;-) Thank again, Paolo Andy Seaborne wrote: > I can see a way it might go wrong if you are using the same dataset Java > object in "dataset.begin(READ)", "dataset.begin(WRITE)". It will > switch the first one to the second transactions, and that will trigger > the concurrency check. > > (The documentation does not explain this, and indeed, is almost > misleading on the subject.) > > Instead, a app idiom of one dateset per thread. The "Dataset" concept > incorporates the JDBC connection concept so it's like Connection pools. > > I'll add some checking code as well. > > > A way to use transactions that should work in the released system is to > do this on one thread: > > Dataset dataset1 = TDBFactory.create(location) ; > dataset1.begin(READ) ; > ... > > and on the other thread: > > Dataset dataset2 = TDBFactory.create(location) ; > dataset2.begin(WRITE) ; > ... > > i.e. different dataset objects (they get backed by the same safe > datastorage). > > I may be able to come up with a cleaner solution but I'd (Mildly) prefer > not to use thread local variables as it's only a partial fix. > > Datasets are quite cheap to create and TDBFactory.create(location) gets > all the caching thing right. > > If, for some reason, you are using in-memory TDB databases, then the use > of "named memory locations" should work. Location.mem("X"). > > Andy
