At one time I had a similar requirement, we did not have a requirement for an update to be immediately available. My solution was to wrap the model/graph layer so that all writes were written to a queue and a single thread processed the writes. We ended up writing transaction blocks to the queue to support write grouping.
Claude On Sat, Jul 20, 2013 at 11:33 AM, Billig, Andreas < andreas.bil...@fokus.fraunhofer.de> wrote: > Hello team, > > we have to use tdb in a setting where we cannot follow the "one > transaction per thread" idiom because the threads are not under our > control. So, according to the docu statement > > (*) "Applications needing to do so must ensure that only one thread starts > the transaction, via a Dataset object, and that all threads are acting > 'multiple reader OR single writer'" > > we have one global transaction object T, which is started in only one > thread, and share T between thread t-1 to t-n. > We also ensure that only one thread t-i can be a writer. Is this enougth, > i.e., have I interpreted the docu in the right way ??? > > thanks in advance, Andreas > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/user.php?cla...@xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
