Sorry my pseudo code was sooo confusing.
Here's something better
synchronized(ctx)
{
while (ctx.isLocked()) {
ctx.wait(5000);
if (ctx.isLocked()) {
log.log("LOCKING-WAITING");
}
else
{
ctx.lock();
break;
}
}
}
// do stuff...
synchronized(ctx)
{
ctx.unlock();
ctx.notify();
}
I think this, or something like it, will work....Important to note....I
don't think you should catch InterruptedException because I'm not sure how
Transaction Timeouts work.
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Georg
> Rehfeld
> Sent: Wednesday, June 06, 2001 8:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
> READ-ONLY Beans)
>
>
> Hi,
>
> > > Bill Burke wrote:
> > > It's not this same. Basically you have a loop to check to see if the
> > > transaction has been commited or unlocked, but you put a wait of 5
> seconds
> > > in there. After the 5 seconds if you're still not locked loop again.
>
> > Dan Christopherson:
> > I don't understand what is different between the two. Are you saying to
> > have only one place where we wait? If so I agree.
>
> one place for the wait sounds good, not having to notify sounds good
> (to me, as I still can't imagine where to place notify), but waiting
> 5 seconds sounds very bad (as Vinay already said: your clients
> would go shopping elsewhere!) compared to the load tests showing
> 90ms response time without concurrency. And I'm sure response time
> can be lower than 30ms with not so large tables and other DB systems
> and read only access (my preleminary tests with MySQL, small tables,
> isModify() implemented, BMP, access read only via a Servlet has
> <20ms processing time for the doGet() method).
>
> From Bills pseudo code I can't imagine where exactly to wait and on
> which object; Dan said it already, wait on the Interceptor will
> affect every access to the entity; wait inbetween mutex.aquire()
> and mutex.release() would block access to the interceptor totally.
>
> If Dan's idea to wait on the mutex turns out to be right, we had
> that one place for the wait too (same place as in my first attempt!?)
> but we surely need notify for cases where i.e. only two clients
> attempt concurrent access and response times are near 10ms.
> Where to put that damn notify(), please, somebody teach me!
>
> > > Bill:
> > > OT, how does transaction timeout destroy the thread? TIA.
>
> OT, TIA, hugh?
>
> Do you mean my DEADLOCKTIMEOUT, if so, then when the EJBException
> reaches thread.run() it should terminate.
>
> Do you mean a transaction timeout somewhere else? If so, in my
> case, where I once recognized the LOCKING-WAITING repeating message
> the first time, there was no transaction timeout at all ...
> but this might be due to the fact that JBoss died after eating
> up ALL of my 5 GByte of disk space by filling my server.log with
> millions of identical messages within few minutes.
>
> bye
> Georg
> ___ ___
> | + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
> |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
