On Wednesday 22 January 2003 12:33 pm, Just van den Broecke wrote: > Hi, > > Looking at the bridge API (v1.5.1) and implementation it looks like it > is single-threaded (only one thread is supposed to access a Cloud > instance). I.e. it is not intended to be thread-safe. In most cases each > http session w/s/could refer to one Cloud instance so this would not be > a problem. But when accessing a single Cloud instance from multiple > threads then synchronization problems could arise? All static objects > (e.g. Node-cache) seem to be thread-safe (synchronized access). Is this > assumption right ? I could not find relevant documentation on the > threading model used.
I think you are right the bridge class instances are not writen to be accessed by multiple thread (they are moostly wrapper objects). each node/object is cloud/transaction specific (cloud1.getNode(123) != cloud2.getNode(123)) and nodes aquired from different transactions / instances can't for example be "related" At lower level (MMObjectNodes) and Caches etc are written for concurent access. Im not shure about this but I Think that if 2 transactions edit the same node there is no way they know about each other (last commit == lucky) > > One approach I experiment is to share multiple Cloud instances (and > Transactions) through ThreadLocal, i.e. "Cloud-pooling". Then only one > thread is guaranteed to access a Cloud instance. Together with pooled > Threads (tomcat) the number of Cloud instances would be significantly > smaller than with "a Cloud-per-http-session" (when the number of http > sessions is higher then the number of pooled threads). Is this sensible ? I don't think the overhead of the bridge classes is that big that it makes sence pooling the cloud instance. > > thanks, > > --Just (working on projects at http://www.waag.org) -- Kees Jongenburger Mediapark C101 Hilversum +31 (0)35 6772910
