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
: 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
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
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
, 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
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
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
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
-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
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
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
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: [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
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
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
/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
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())
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
18 matches
Mail list logo
