I think we should keep James using Avalon's utilities, ie Lock. If there is a problem with them, the change should happen at the Avalon level. So, someone needs to sit down and hack through James updating the locks. No promises!
By the way, I would prefer to get Gump build errors than have duplicated lock code. Charles Harmeet Bedi wrote: > > ----- Original Message ----- > From: "Berin Loritsch" <[EMAIL PROTECTED]> > > The Lock implementation DID NOT WORK in its previous form. For some > reason, > > when we had one Lock object handle the locks for multiple objects, the > Lock > > would not prevent access. This caused some concurrency issues in the Pool > > implementations. The API was changed to lock() and unlock() with no > parameters. > > canLock() and isLocked() were not implemented, as I didn't think they were > > truly useful. They can be added back in, but without ANY params. I was > > focusing on getting something that really worked. > > > > I did post an email about this to the Avalon Dev list when I committed it, > > but it looks like noone read it. > > I did read it, but did had no cycles to follow up or think about the impact. > I have for now added the old Avalon Lock Classes to James. This is a stopgap > measure otherwise James would suffer from the same problems you found in > Cocoon. James does seem to rely on the previous Lock API. Maybe the same API > can be built in some other object using the new Lock implementation. > > > > > If we want to adopt the aquire()/release() names, it's nothing but a name > > thing. The contents change with the InterruptedException is excellent, > > and can help prevent some deadlocks. I will incorporate that. > > > > But lets vote on the "Class : Method" names: > > > > 1) Mutex : aquire()/release() > > 2) Lock : lock()/unlock() > > > > I have no qualms or preferences about either--I just want this thing to > > work properly. > > Names don't matter that much however if Avalon can use or reuse a standard > package, than the same names should be mentained. Well my vote is not > important and in any case it is 0. > > > > > > I think one should reuse a solid concurrency management library if it is > > > available. I think one should consider Doug Lea's package as a > reasonable > > > and stable candidate. Anyway not sure how to fix the James build in a > safe > > > manner, hope someone knows how to. > > > > OK. I was working on what was already in Avalon. If there is a solid > > concurrency management library available with a compatible license, then > > go for it. Note, we did have someone express interest in donating or > > developing a number of classes that would fill this need. > > I make lots of multithreading mistakes. Would prefer to rely on a well > tested, widely reviewed and fast library. But that is sometimes a chicken > and egg problem. Not sure if there is a need for a new implementation, but > if there is, good to get it done and available as part of Avalon. :-) > > Harmeet > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
