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
