Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hi,
First of all, thanks for the contribution. Things get done when
people jump in and contribute their time, and we definitely have a
scaling problem we need to fix.
If I understand the implications of your code, I'm very against this
particular solution, as it is a violation of the EJB spec and will also
create concurrency problems unless the EJB component is also
written in violation of the spec. (This is nothing against you; this
approach has been suggested before.)
Bottom line: if I'm correct that this allows multi-threaded access to
a single entity instance, I think you should take it out. The correct
solution to the locking problem as I see it is slightly more work:
add support for multiple instances of entities associated with the
same primary key for commit option C. See my previous post.
Of course, others may disagree, so this is just my opinion. I hope
Marc, Juha, Simone, Rickard, etc. will offer their opinions, as this
is a pretty key piece of code. Maybe they can talk about it at Java
One. :-)
I might be wrong about what is going on, or about the ultimate
utility of this piece of code. But it is a key piece of code for the
container, and needs to be reviewed carefully.
-Dan
On 6 Jun 01, at 9:32, K.V. Vinay Menon wrote:
Hello,
In order to avoid locking for TX or CTX in the EntityInstanceInterceptor, I've
basically added a flag to indicate whether the bean can be optimized for read only
operation. In the EntityInstanceInterceptor, where the loop actually wait for the
lock I've added a condition
isReadOptimized = metadata.isReadOptimized();
if(!isReadOptimized)
{
...
...
go about as usual trying to aquire lock etc
}
mi.setEnterpriseContext(ctx);
return getNext().invoke(mi);
and in the finally clause
if (ctx != null (!isReadOptimized))
{
//business as usual code
}
What is good is that I no longer have my response times creeping up
under sustained
loads.
Does this look alright? Does anyone anticipate any other problems due
to this. Wou
ld really appreciate if folks who really have the 'bigger picture' can let me know.
Thanks
Vinay
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
My view is if the new option to have multiple bean instances is going to
take long to write why should we be bothered about concurrency in a read
only bean?
Vinay
- Original Message -
From: Dan OConnor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 1:26 PM
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hi,
First of all, thanks for the contribution. Things get done when
people jump in and contribute their time, and we definitely have a
scaling problem we need to fix.
If I understand the implications of your code, I'm very against this
particular solution, as it is a violation of the EJB spec and will also
create concurrency problems unless the EJB component is also
written in violation of the spec. (This is nothing against you; this
approach has been suggested before.)
Bottom line: if I'm correct that this allows multi-threaded access to
a single entity instance, I think you should take it out. The correct
solution to the locking problem as I see it is slightly more work:
add support for multiple instances of entities associated with the
same primary key for commit option C. See my previous post.
Of course, others may disagree, so this is just my opinion. I hope
Marc, Juha, Simone, Rickard, etc. will offer their opinions, as this
is a pretty key piece of code. Maybe they can talk about it at Java
One. :-)
I might be wrong about what is going on, or about the ultimate
utility of this piece of code. But it is a key piece of code for the
container, and needs to be reviewed carefully.
-Dan
On 6 Jun 01, at 9:32, K.V. Vinay Menon wrote:
Hello,
In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to indicate whether
the bean can be optimized for read only operation. In the
EntityInstanceInterceptor, where the loop actually wait for the lock I've
added a condition
isReadOptimized = metadata.isReadOptimized();
if(!isReadOptimized)
{
...
...
go about as usual trying to aquire lock etc
}
mi.setEnterpriseContext(ctx);
return getNext().invoke(mi);
and in the finally clause
if (ctx != null (!isReadOptimized))
{
//business as usual code
}
What is good is that I no longer have my response times
creeping up under sustained
loads.
Does this look alright? Does anyone anticipate any other
problems due to this. Wou
ld really appreciate if folks who really have the 'bigger picture' can let
me know.
Thanks
Vinay
___
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
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hi Vinay,
see below
In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to
indicate whether the bean can be optimized for read only
operation. In the EntityInstanceInterceptor, where the loop
actually wait for the lock I've added a condition
isReadOptimized = metadata.isReadOptimized();
if(!isReadOptimized)
{
...
...
go about as usual trying to aquire lock etc
}
mi.setEnterpriseContext(ctx);
return getNext().invoke(mi);
and in the finally clause
if (ctx != null (!isReadOptimized))
{
//business as usual code
}
What is good is that I no longer have my response times creeping
up under sustained loads. Does this look alright? Does anyone
anticipate any other problems due to this. Would really
appreciate if folks who really have the 'bigger picture' can let
me know.
Might be better you provide a context diff to us, so we more
exactly can see what you plan to do (change code, do
cvs diff -u EntityInstanceInterceptor.java).
As far as I understand, you skip the whole
do { ... } while (ctx == null); loop? So you end up with a null
EnterpriseContext, not a good idea IMHO, because i.e. security
and transactional settings (amoung other important things) are
attached to it, most likely invoked other interceptors rely on
the ctx set?!
Where does your isReadOptimized come from, JAWS? If so, the BMP
developers are left alone.
I still would insist on the correction of the missing wait/notify
issue, as I still believe that the extremly bad response times
under load are more caused by several threads executing tight
loops consuming most of the cpu time instead of simply waiting
and let the cpu to JBoss doing real work!
I'm NOT a multithreading expert though. My first thought was to
simply insert a wait() directly after the two
Logger.debug(LOCKING-WAITING ...); calls and a notifyAll()
after the ctx.unlock() in the finally clause, but I've 2 problems
with this approach:
1. there is a mutex.aquire()/mutex.release() pair; when I simply
would wait inbetween, I think no other thread can enter the code
thus rendering EntityInstanceInterceptor dead, when one thread is
waiting, on the other hand, I can't simply release the mutex
there, it's a critical section. A solution would be to have a
wait directly before the } while (ctx == null); if ctx == 0 as of
this (hand made) context diff:
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
+ if (ctx == null) {
+ // let the thread that has the lock proceed
+ // at same time let's detect possible deadlock
+ long start = System.getCurrentTimeMillis();
+ try {
+ wait(DEADLOCKTIMEOUT + 1000);
+ }
+ catch (InterruptedException ignored) {}
+ finally {
+ if (System.getCurrentTimeMillis() - start
+DEADLOCKTIMEOUT)
+ {
+ throw new EJBException(
+ possible deadlock detected);
+ }
+ }
+ }
} while (ctx == null);
...
...
else
{
// Yeah, do nothing
}
+ notifyAll();
}
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
2. the notifyAll() above better should not awake any thread in
JBoss, but better only the threads that wait above, hmmm, isn't
this implicit? Do we need thread groups? It would be
best/required that the Interceptor only waits, when the same bean
instance is to be entered concurrently (this should be so
already) and that only exactly the threads, that wait on the same
instance should wake up. Please remember, I'm unexperienced with
multithreding and JBoss, just lost on this.
___ ___
| + | |__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
RE: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
I suppose it would get us out of the problem of being certified as J2EE compliant as well... -Original Message- From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans OK! I know that it is kind of controversial and that its spec violation and stuff but why can't we have multi threaded beans for read-only cases? Why should we be bothered about transactions? We don't lock the database for selects do we? Non-purists who face real world performance issues - please let me know if these is complete rubbish or is something that 'could' prove useful.. unless someone voluteers to write the code for multiple bean instances per home handle! snip/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
OK!
I know that it is kind of controversial and that its spec violation and
stuff but why can't we have multi threaded beans for read-only cases? Why
should we be bothered about transactions? We don't lock the database for
selects do we? Non-purists who face real world performance issues - please
let me know if these is complete rubbish or is something that 'could' prove
useful.. unless someone voluteers to write the code for multiple bean
instances per home handle!
Vinay
- Original Message -
From: Georg Rehfeld [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 1:35 PM
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hi Vinay,
see below
In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to
indicate whether the bean can be optimized for read only
operation. In the EntityInstanceInterceptor, where the loop
actually wait for the lock I've added a condition
isReadOptimized = metadata.isReadOptimized();
if(!isReadOptimized)
{
...
...
go about as usual trying to aquire lock etc
}
mi.setEnterpriseContext(ctx);
return getNext().invoke(mi);
and in the finally clause
if (ctx != null (!isReadOptimized))
{
//business as usual code
}
What is good is that I no longer have my response times creeping
up under sustained loads. Does this look alright? Does anyone
anticipate any other problems due to this. Would really
appreciate if folks who really have the 'bigger picture' can let
me know.
Might be better you provide a context diff to us, so we more
exactly can see what you plan to do (change code, do
cvs diff -u EntityInstanceInterceptor.java).
As far as I understand, you skip the whole
do { ... } while (ctx == null); loop? So you end up with a null
EnterpriseContext, not a good idea IMHO, because i.e. security
and transactional settings (amoung other important things) are
attached to it, most likely invoked other interceptors rely on
the ctx set?!
Where does your isReadOptimized come from, JAWS? If so, the BMP
developers are left alone.
I still would insist on the correction of the missing wait/notify
issue, as I still believe that the extremly bad response times
under load are more caused by several threads executing tight
loops consuming most of the cpu time instead of simply waiting
and let the cpu to JBoss doing real work!
I'm NOT a multithreading expert though. My first thought was to
simply insert a wait() directly after the two
Logger.debug(LOCKING-WAITING ...); calls and a notifyAll()
after the ctx.unlock() in the finally clause, but I've 2 problems
with this approach:
1. there is a mutex.aquire()/mutex.release() pair; when I simply
would wait inbetween, I think no other thread can enter the code
thus rendering EntityInstanceInterceptor dead, when one thread is
waiting, on the other hand, I can't simply release the mutex
there, it's a critical section. A solution would be to have a
wait directly before the } while (ctx == null); if ctx == 0 as of
this (hand made) context diff:
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
+ if (ctx == null) {
+ // let the thread that has the lock proceed
+ // at same time let's detect possible deadlock
+ long start = System.getCurrentTimeMillis();
+ try {
+ wait(DEADLOCKTIMEOUT + 1000);
+ }
+ catch (InterruptedException ignored) {}
+ finally {
+ if (System.getCurrentTimeMillis() - start
+DEADLOCKTIMEOUT)
+ {
+ throw new EJBException(
+ possible deadlock detected);
+ }
+ }
+ }
} while (ctx == null);
...
...
else
{
// Yeah, do nothing
}
+ notifyAll();
}
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
2. the notifyAll() above better should not awake any thread in
JBoss, but better only the threads that wait above, hmmm, isn't
this implicit? Do we need thread groups? It would be
best/required that the Interceptor only waits, when the same bean
instance is to be entered concurrently (this should be so
already) and that only exactly the threads, that wait on the same
instance should wake up. Please remember, I'm unexperienced with
multithreding and JBoss, just lost
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
It may well be usefull, but does this behavior belong in the normal EntityInstanceInterceptor? Why not just implement an non-blocking variant of EntityInstanceInterceptor, and reconfigure your stack in jboss.xml? K.V. Vinay Menon wrote: OK! I know that it is kind of controversial and that its spec violation and stuff but why can't we have multi threaded beans for read-only cases? Why should we be bothered about transactions? We don't lock the database for selects do we? Non-purists who face real world performance issues - please let me know if these is complete rubbish or is something that 'could' prove useful.. unless someone voluteers to write the code for multiple bean instances per home handle! Vinay Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Bill Burke wrote: - What's wrong with doing a Context lock, but not doing a transactional lock for read-only beans? won't you still block on the context lock? If you do this you'll still be spec compliant, correct? How would this affect your performance results? I'm pretty sure the spec says it's up to the Container developer to decide how to synch beans per transaction, but you are required to make EntityBeans single threaded. - Which xml file has the flag (isReadOptimized)? IMHO, if this read-only thing is accepted, this flag for it should be in jboss.xml, not jaws.xml, so that BMP developers have access to it. I agree, if it's there at all. - All in all, IMHO, Transactional EntityBean locking should be removed totally from JBoss. This locking is totally useless when you have more than one instance of JBoss hitting the sam DB anyways. Let the DB handle the locking. If you want your EntityBeans synched across transactions use the select-for-update options if you're using CMP, or with BMP, manage the DB locks yourself. Being able to specify the transaction isolation level for your CMP beans would also let us control concurrent access better. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
danch (Dan Christopherson) wrote: Georg Rehfeld wrote: One problem here is that when we're waiting on the context, we want to wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000)) Just doing wait and notifyAll on the interceptor itself will involve all calls on our entity when we just want to handle contention for the one context. The other problem is that if we're waiting on the transaction, we don't want to do wait/notify on the context - I don't know what we do want to wait on, but we really need to know when the transaction ends. Actually, looking closer at the code, it's probably the mutex that we want to wait on in both cases - it is specific to the key involved. Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
RE: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5 second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
danch (Dan Christopherson) wrote:
Georg Rehfeld wrote:
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000))
Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity when we just want to handle contention for the one context.
The other problem is that if we're waiting on the transaction, we don't
want to do wait/notify on the context - I don't know what we do want to
wait on, but we really need to know when the transaction ends.
Actually, looking closer at the code, it's probably the mutex that we
want to wait on in both cases - it is specific to the key involved.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Very true! I could do that. That way folks who want to use it can use it. Vinay - Original Message - From: danch (Dan Christopherson) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 5:37 PM Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans It may well be usefull, but does this behavior belong in the normal EntityInstanceInterceptor? Why not just implement an non-blocking variant of EntityInstanceInterceptor, and reconfigure your stack in jboss.xml? K.V. Vinay Menon wrote: OK! I know that it is kind of controversial and that its spec violation and stuff but why can't we have multi threaded beans for read-only cases? Why should we be bothered about transactions? We don't lock the database for selects do we? Non-purists who face real world performance issues - please let me know if these is complete rubbish or is something that 'could' prove useful.. unless someone voluteers to write the code for multiple bean instances per home handle! Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Wednesday, June 06, 2001 1:11 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans Hello Bill, hi all, - What's wrong with doing a Context lock, but not doing a transactional lock for read-only beans? If you do this you'll still be spec compliant, correct? How would this affect your performance results? I'm pretty sure the spec says it's up to the Container developer to decide how to synch beans per transaction, but you are required to make EntityBeans single threaded. It was reported, that trying to access the beans concurrently without TX and with non-reentrant beans leads to very similar LOCKING-WAITING behaviour as within a TX. But if you access outside a TX AND have the bean reentrant there is no LOCKING-WAITING anymore without any change to existing code. I don't think, this reentrnce really is a problem, data gotten outside a TX must be considered inconsistent anyway, so why not let hundreds of clients do getters concurrently, where is the problem? Concurrent access from clients accessing inside different TXs is still serialized, the only potential danger with reentrant is, when DIFFERENT clients having THE SAME TX access the bean concurrently, how should this normally be possible (except for the allowed callback case)? Before modifying code that makes JBoss incompliant, why not simply use existing spec conform features, it's all there, just use it! - All in all, IMHO, Transactional EntityBean locking should be removed totally from JBoss. This locking is totally useless when you have more than one instance of JBoss hitting the sam DB anyways. Let the DB handle the locking. If you want your EntityBeans synched across transactions use the select-for-update options if you're using CMP, or with BMP, manage the DB locks yourself. Oh, but then you cannot use commit option A anymore. So for A the serialization IS required, and with B and C someone has to implement multiple instances of the bean before removing the locking at container level. Why do you have to implement multiple instances of the bean? For a quick fix, just take out the code that waits for the EntityBean to leave the transaction in EntityInstanceInterceptor. Leave the locking code that comes after the transaction waiting stuff, it's used to make the bean single-threaded(correct?). This will still work for commit-option 'A' won't it? If you keep the bean single-threaded, option 'A' is not violated. What about this scenario: == Transaction A Transaction B Lock Entity B Context Wait for entity b context. Call into business method Modify data Unlock Entity B Context Lock entity B Context Read data A Modified Rollback! = Now transaction B has read data that has never been modified. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
RE: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
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.
OT, how does transaction timeout destroy the thread? TIA.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 3:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
I think that's roughly equivalent to Georg's 'wait(DEADLOCKTIMEOUT +
1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
Bill Burke wrote:
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5
second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
danch (Dan Christopherson) wrote:
Georg Rehfeld wrote:
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000))
Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity when we just want to handle contention for the one context.
The other problem is that if we're waiting on the transaction, we don't
want to do wait/notify on the context - I don't know what we do want to
wait on, but we really need to know when the transaction ends.
Actually, looking closer at the code, it's probably the mutex that we
want to wait on in both cases - it is specific to the key involved.
___
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
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
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.
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.
OT, how does transaction timeout destroy the thread? TIA.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 3:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
I think that's roughly equivalent to Georg's 'wait(DEADLOCKTIMEOUT +
1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
Bill Burke wrote:
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5
second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
danch (Dan Christopherson) wrote:
Georg Rehfeld wrote:
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000))
Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity when we just want to handle contention for the one context.
The other problem is that if we're waiting on the transaction, we don't
want to do wait/notify on the context - I don't know what we do want to
wait on, but we really need to know when the transaction ends.
Actually, looking closer at the code, it's probably the mutex that we
want to wait on in both cases - it is specific to the key involved.
___
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
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
To be honest if the response time for a lookup is 5 seconds your clients
would go shopping elsewhere!
Vinay
- Original Message -
From: danch (Dan Christopherson) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 9:48 PM
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
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.
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.
OT, how does transaction timeout destroy the thread? TIA.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 3:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
I think that's roughly equivalent to Georg's 'wait(DEADLOCKTIMEOUT +
1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
Bill Burke wrote:
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5
second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks
for
READ-ONLY Beans)
danch (Dan Christopherson) wrote:
Georg Rehfeld wrote:
One problem here is that when we're waiting on the context, we want
to
wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000))
Just doing
wait and notifyAll on the interceptor itself will involve all calls
on
our entity when we just want to handle contention for the one
context.
The other problem is that if we're waiting on the transaction, we
don't
want to do wait/notify on the context - I don't know what we do want
to
wait on, but we really need to know when the transaction ends.
Actually, looking closer at the code, it's probably the mutex that we
want to wait on in both cases - it is specific to the key involved.
___
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
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Certification ceases to make any business sense when performance sucks! The customer is not bothered if you are running a J-2-E-E compliant / certified app server. They are not even bothered if you use Java or COBOL as long as they get what they want - a good user experience.At some point we have to come out of shells of java purism and get some business sense into things. Vinay - Original Message - From: Jay Walters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 4:55 PM Subject: RE: [JBoss-dev] Avoiding Locks for READ-ONLY Beans I suppose it would get us out of the problem of being certified as J2EE compliant as well... -Original Message- From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans OK! I know that it is kind of controversial and that its spec violation and stuff but why can't we have multi threaded beans for read-only cases? Why should we be bothered about transactions? We don't lock the database for selects do we? Non-purists who face real world performance issues - please let me know if these is complete rubbish or is something that 'could' prove useful.. unless someone voluteers to write the code for multiple bean instances per home handle! snip/ ___ 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
RE: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
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 workImportant to noteI
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
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
OK, I think we're talking about the same sort of thing. This looks good.
Bill Burke wrote:
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 workImportant to noteI
don't think you should catch InterruptedException because I'm not sure how
Transaction Timeouts work.
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
K.V. Vinay Menon wrote: To be honest if the response time for a lookup is 5 seconds your clients would go shopping elsewhere! 5 seconds is the worst case: normally you'll be notified long before that happens. Actually 5 seconds is so much worst case that that's probably about the point where you decide that you must have a deadlock and roll yourself back to save the other transaction. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
