Hi, On Fri, 2010-08-13 at 17:40 -0500, Carsten Neumann wrote: > Hello all, > > we've run into a problem with our app that runs multiple threads on one > aspect when connecting it to a cluster server. > Consider the following scenario: > > Thread A: > - changes field F0 in container C > in FC::registerChangedContainer _pContainerChanges points to an entry in > the CL of Thread A. > - commitChanges(); > > Thread B: > - changes field F1 in container C > because of the commitChanges _bvChanges == 0x00 > so FC::registerChangedContainer runs, but only puts an uncommitted > change for F1 into the CL of Thread B. > - commitChanges(); > > The change to F1 will not be transmitted over the cluster, because it is > lost after the commitChanges clears the uncommitedChanges list of the CL > of Thread B.
hmm, the thing missing is how and when do you set up the change list for the cluster sync ?? Which relates to how are A and B excluded from each other, e.g. how fine grained is the locking so that they do not write the same container ? > Attached is a patch that changes the behaviour of > FC::registerChangedContainer() to only skip creation of a new CL entry > if _pContainerChanges points into the current thread's CL. > > Comments? Other ideas to solve this? if possible I would like to avoid the round trip through the thread. kind regards gerrit ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
