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]
