> I think it would be better to design the objects to only maintain > references to other objects by pk, so that when the objects are > requested their status of whether there is a read or write lock can be > determined, or the objects themselves should contain this information.
hmmmm...but that wouldn't be very object-oriented would it? Objects are also coupled to the persistence mechanism. OTOH, if a proxy object is used, that'd be pretty interesting. > But I have not put enough thought into it. If the objects can be left > as is and any MT issues taken care of by the cache that would be great, > but I have my doubts. I doubt it too. At least from how I'd approach it, I'll have to rely on the honesty of clients to explicitly acquire the write-lock when writing, and to not modify the object when requesting read-only. > > In scarab with Attributes and a few other objects that are being cached, > they are mostly used in a read-only manner. The code that makes changes > to them has to be implemented with thread safety in mind. Hopefully, > this is maintained through all the code changes that occur while > building and maintaining the app, but it is not a good solution. Agreed. The contract should be made more explicit. Kelvin > > john mcnally > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
