RE: [JBoss-user] Unable to passivate due to ctx lock

2004-02-05 Thread Stephane Nicoll
Typical case is as follows:

you start a JTA transaction, then pool an important number of entity bean
(let's say a findAll() or something). The entity bean pool is then full so it
starts putting entity bean in the passivate state but it can't because those
are still enlisted in the JTA transaction you created.

Solution is to increase the pool size (see container configuration).

Regards,

Stephane

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 04, 2004 4:00 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Unable to passivate due to ctx lock


Hello,

for me, it seems that such a ctx is locked when an invocation is currently
active in a bean instance. We encounter such a warning
message if the container tries to passivate such an instance. It depends on
the time methods need to execute and the frequency of
invocations and passivation trials.
We use commit-optionD/commit-option with a refresh rate of 30 seconds
(the container tries to passivate bean instances then) and
encounter the same warning message if a client currently calls a bean method.

My questions is: How is such a situation resolved? Tries the container again
and when? Can it be that a bean instance is never
passivated (refreshed) if sequently passivation trials are unsuccessful or
are passivation trials enqueued or reminded with a flag
in something associated with the instance (ctx?) so that instances are
definitely passivated by the container right after the
locking invocation returns?

Thanks,
S. Pohl

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Auftrag von Marek
 Lange
 Gesendet: Mittwoch, 4. Februar 2004 15:21
 An: JBoss User
 Betreff: [JBoss-user] Unable to passivate due to ctx lock


 After switching from 3.0.6 to 3.2.3 we experience warning messages in
 our logfiles:

 WARN  [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to
 passivate
 due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x

 This seems to be a problem to passivate (a stateful session?) bean.
 Looking into the code, the context of the bean seems to be locked:

 protected boolean canPassivate(EnterpriseContext ctx)
 {
 if (ctx.isLocked())
 {
// The context is in the interceptor chain
return false;
 }
 ...

 Is there a way to discover what is holding the lock on the
 context? What
 is the impact of that warning for our application?

 Thanks,

 -marek



 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


RE: [JBoss-user] Unable to passivate due to ctx lock

2004-02-05 Thread Adrian Brock
You mean cache not pool.

Regards,
Adrian

On Wed, 2004-02-04 at 16:28, Stephane Nicoll wrote:
 Typical case is as follows:
 
 you start a JTA transaction, then pool an important number of entity bean
 (let's say a findAll() or something). The entity bean pool is then full so it
 starts putting entity bean in the passivate state but it can't because those
 are still enlisted in the JTA transaction you created.
 
 Solution is to increase the pool size (see container configuration).
 
 Regards,
 
 Stephane
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, February 04, 2004 4:00 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-user] Unable to passivate due to ctx lock
 
 
 Hello,
 
 for me, it seems that such a ctx is locked when an invocation is currently
 active in a bean instance. We encounter such a warning
 message if the container tries to passivate such an instance. It depends on
 the time methods need to execute and the frequency of
 invocations and passivation trials.
 We use commit-optionD/commit-option with a refresh rate of 30 seconds
 (the container tries to passivate bean instances then) and
 encounter the same warning message if a client currently calls a bean method.
 
 My questions is: How is such a situation resolved? Tries the container again
 and when? Can it be that a bean instance is never
 passivated (refreshed) if sequently passivation trials are unsuccessful or
 are passivation trials enqueued or reminded with a flag
 in something associated with the instance (ctx?) so that instances are
 definitely passivated by the container right after the
 locking invocation returns?
 
 Thanks,
 S. Pohl
 
  -Ursprngliche Nachricht-
  Von: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Auftrag von Marek
  Lange
  Gesendet: Mittwoch, 4. Februar 2004 15:21
  An: JBoss User
  Betreff: [JBoss-user] Unable to passivate due to ctx lock
 
 
  After switching from 3.0.6 to 3.2.3 we experience warning messages in
  our logfiles:
 
  WARN  [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to
  passivate
  due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x
 
  This seems to be a problem to passivate (a stateful session?) bean.
  Looking into the code, the context of the bean seems to be locked:
 
  protected boolean canPassivate(EnterpriseContext ctx)
  {
  if (ctx.isLocked())
  {
 // The context is in the interceptor chain
 return false;
  }
  ...
 
  Is there a way to discover what is holding the lock on the
  context? What
  is the impact of that warning for our application?
 
  Thanks,
 
  -marek
 
 
 
  ---
  The SF.Net email is sponsored by EclipseCon 2004
  Premiere Conference on Open Tools Development and Integration
  See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
  http://www.eclipsecon.org/osdn
  ___
  JBoss-user mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-user
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user
-- 
 
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC 
 



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


[JBoss-user] Unable to passivate due to ctx lock

2004-02-04 Thread Marek Lange
After switching from 3.0.6 to 3.2.3 we experience warning messages in 
our logfiles:

WARN  [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to passivate 
due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x

This seems to be a problem to passivate (a stateful session?) bean. 
Looking into the code, the context of the bean seems to be locked:

protected boolean canPassivate(EnterpriseContext ctx)
{
   if (ctx.isLocked())
   {
  // The context is in the interceptor chain
  return false;
   }
...
Is there a way to discover what is holding the lock on the context? What 
is the impact of that warning for our application?

Thanks,

-marek



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


RE: [JBoss-user] Unable to passivate due to ctx lock

2004-02-04 Thread spohl
Hello,

for me, it seems that such a ctx is locked when an invocation is currently active in a 
bean instance. We encounter such a warning
message if the container tries to passivate such an instance. It depends on the time 
methods need to execute and the frequency of
invocations and passivation trials.
We use commit-optionD/commit-option with a refresh rate of 30 seconds (the 
container tries to passivate bean instances then) and
encounter the same warning message if a client currently calls a bean method.

My questions is: How is such a situation resolved? Tries the container again and when? 
Can it be that a bean instance is never
passivated (refreshed) if sequently passivation trials are unsuccessful or are 
passivation trials enqueued or reminded with a flag
in something associated with the instance (ctx?) so that instances are definitely 
passivated by the container right after the
locking invocation returns?

Thanks,
S. Pohl

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Auftrag von Marek
 Lange
 Gesendet: Mittwoch, 4. Februar 2004 15:21
 An: JBoss User
 Betreff: [JBoss-user] Unable to passivate due to ctx lock


 After switching from 3.0.6 to 3.2.3 we experience warning messages in
 our logfiles:

 WARN  [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to
 passivate
 due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x

 This seems to be a problem to passivate (a stateful session?) bean.
 Looking into the code, the context of the bean seems to be locked:

 protected boolean canPassivate(EnterpriseContext ctx)
 {
 if (ctx.isLocked())
 {
// The context is in the interceptor chain
return false;
 }
 ...

 Is there a way to discover what is holding the lock on the
 context? What
 is the impact of that warning for our application?

 Thanks,

 -marek



 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


Re: [JBoss-user] Unable to passivate due to ctx lock

2004-02-04 Thread Russell Chan
Marek,

You aren't perchance using Handle.getEJBObject() in your client app/webapp are you?

If so, search this mailing lists archive for my prior post about Handle.getEJBObject().

I think that there may be a new bug introduced in the 3.2 series that causes an 
additional
extra ref lock on the stateful bean.
If you're not using that call, then there is likely a chance that some ivars of 
your
session bean can't be serialized...
Regards,
Russ Chan
Marek Lange wrote:
After switching from 3.0.6 to 3.2.3 we experience warning messages in 
our logfiles:

WARN  [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to passivate 
due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x

This seems to be a problem to passivate (a stateful session?) bean. 
Looking into the code, the context of the bean seems to be locked:

protected boolean canPassivate(EnterpriseContext ctx)
{
   if (ctx.isLocked())
   {
  // The context is in the interceptor chain
  return false;
   }
...
Is there a way to discover what is holding the lock on the context? What 
is the impact of that warning for our application?

Thanks,

-marek



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
--
--
Russell Chan,
Navaho Networks Inc.
416 542 1590 x108


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


Re: [JBoss-user] Unable to passivate due to ctx lock

2004-02-04 Thread Roy Britten
Hi,

I've had a search through this list's archives, and haven't found a
definite resolution to this issue.

We're seeing this warning on a very low-traffic site, and while it hasn't
caused any significant issues so far I don't want to run into the memory
leakage problems reported elsewhere.

A rummage through the (v3.2.1) source code has caused me to post the
following, in the hope that someone more familiar with the source can
comment:

BeanLockManager.getLock() is documented with the warning:
* WARNING: All access to this method MUST have an equivalent removeLockRef
* cleanup call, or this will create a leak in the map,

Now, JDBCStoreManager.fieldStateEventCallback() and
JDBCStoreManager.getOptimisticLock() both call BeanLockManager.getLock()
*without* calling BeanLockManager.removeLockRef(); instead they call
removeRef() directly on the lock. Is it possible that this is causing the
map of locks in the lock manager to grow?

Someone more familiar with the processes and server state when these
methods are called may be able to assert whether or not this is
in fact the case. Anyone?

Cheers,
Roy.

On Wed, 4 Feb 2004 at 3:20pm, Marek Lange wrote:

 After switching from 3.0.6 to 3.2.3 we experience warning messages in
 our logfiles:

 WARN [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to passivate
 due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x

-- 
Roy Britten
National Institute of Water and Atmospheric Research
PO Box 8602, Christchurch, New Zealand
P: +64-3-343-7818
F: +64-3-348-5548
http://www.niwa.co.nz


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


RE: [JBoss-user] Unable to passivate due to ctx lock

2004-02-04 Thread Adrian Brock
On Wed, 2004-02-04 at 14:59, [EMAIL PROTECTED] wrote:
 Hello,
 
 for me, it seems that such a ctx is locked when an invocation is currently active in 
 a bean instance. We encounter such a warning
 message if the container tries to passivate such an instance. It depends on the time 
 methods need to execute and the frequency of
 invocations and passivation trials.
 We use commit-optionD/commit-option with a refresh rate of 30 seconds (the 
 container tries to passivate bean instances then) and
 encounter the same warning message if a client currently calls a bean method.
 
 My questions is: How is such a situation resolved? Tries the container again and 
 when? Can it be that a bean instance is never
 passivated (refreshed) if sequently passivation trials are unsuccessful or are 
 passivation trials enqueued or reminded with a flag
 in something associated with the instance (ctx?) so that instances are definitely 
 passivated by the container right after the
 locking invocation returns?
 

This is mostly harmless, although there was a bug reported recently
where the lock reference counting was incorrect when using a SFSB
Handle.

In the case of an SFSB where it is trying to passivate to disk,
it is not passivated to disk and is instead promoted to MRU 
(most recently used).
It will try again at the end of the next passivation period.

In the case of commit option D, it is an attempt to return the bean
to the pool. Since it is still in use, 
it is just invalidated in the cache.
The invocation/transaction still has a reference. 
The bean instance will be discarded at the end of the
invocation/transaction.

Regards,
Adrian

 Thanks,
 S. Pohl
 
  -Ursprngliche Nachricht-
  Von: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Auftrag von Marek
  Lange
  Gesendet: Mittwoch, 4. Februar 2004 15:21
  An: JBoss User
  Betreff: [JBoss-user] Unable to passivate due to ctx lock
 
 
  After switching from 3.0.6 to 3.2.3 we experience warning messages in
  our logfiles:
 
  WARN  [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to
  passivate
  due to ctx lock, id=127.0.0.1:1099:dq6o9s7q-x
 
  This seems to be a problem to passivate (a stateful session?) bean.
  Looking into the code, the context of the bean seems to be locked:
 
  protected boolean canPassivate(EnterpriseContext ctx)
  {
  if (ctx.isLocked())
  {
 // The context is in the interceptor chain
 return false;
  }
  ...
 
  Is there a way to discover what is holding the lock on the
  context? What
  is the impact of that warning for our application?
 
  Thanks,
 
  -marek
 
 
 
  ---
  The SF.Net email is sponsored by EclipseCon 2004
  Premiere Conference on Open Tools Development and Integration
  See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
  http://www.eclipsecon.org/osdn
  ___
  JBoss-user mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-user
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user
-- 
 
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC 
 



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


[JBoss-user] Unable to passivate due to ctx lock

2003-07-29 Thread Raghuram
Hi,
I am getting the above warning Unable to passivate due to ctx lock with
jboss 3.2.1 . I've deployed some entity beans
with commit option C and i guess this message relates to that.
I went through the development mailing list and found that this had been
recorded as a thing to be fixed.
What are the implications of this message ?
Should i switch to commit option B ?
regards
raghu



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


[JBoss-user] Unable to passivate due to ctx lock

2003-06-25 Thread Magesh Prabhu
I'm getting this following warning. I went in to all my entity beans to check if I'm 
doing any naughtly stuff with entity context. Everything looks fine. Could anybody 
suggest me what could be the possible reason for this warning.. 

Thanks in advance,
Magesh

WARN  [AbstractInstanceCache] Unable to passivate due to ctx lock, id=PROOFING
WARN  [AbstractInstanceCache] Unable to passivate due to ctx lock, id=PROOFING
WARN  [AbstractInstanceCache] Unable to passivate due to ctx lock, 
id=1878testRequest001



**
This email and its attachments are intended for the above 
named only and may be confidential.  If they have come to 
you in error, you must take no action based on them, nor 
must you copy or show them to anyone; please reply to this 
email and highlight the error.
Security Warning: Please note that this email has been 
created in the knowledge that the internet email is not a 
100% secure communications medium.  We advise that you 
understand and observe this lack of security when emailing us.
Viruses:  Although we have taken steps to ensure that this 
email and attachments are free from any virus, we advise 
that in keeping with good computing practice the recipient 
should ensure they are actually virus free.
If you have received this email in error please notify:
[EMAIL PROTECTED]
**



---
This SF.Net email is sponsored by: INetU
Attention Web Developers  Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


Re: [JBoss-user] Unable to passivate due to ctx lock

2003-06-25 Thread Magesh Prabhu
Alex, I'm using BMP's.

The id's displayed in the warn message is valid. The record definitely exist in 
database.

Cheers,
Magesh

On 6/25/03 12:01 PM, Alexey Loubyansky [EMAIL PROTECTED] wrote:
Hello Magesh,

Wednesday, June 25, 2003, 1:33:27 PM, Magesh Prabhu wrote:

MP I'm getting this following warning. I went in to all my entity 
beans to check if I'm doing any naughtly stuff with entity context. 
Everything looks fine. Could anybody suggest me what could be
MP the possible reason for this warning.. 

For example, a bug in JBoss. Could you provide more info?
Are there foreign key fields mapped to CMP fields?
Are the id's in WARN's valid? meaning really exist in the database?

Thanks,
alex

MP Thanks in advance,
MP Magesh

MP WARN  [AbstractInstanceCache] Unable to passivate due to ctx 
lock, id=PROOFING
MP WARN  [AbstractInstanceCache] Unable to passivate due to ctx 
lock, id=PROOFING
MP WARN  [AbstractInstanceCache] Unable to passivate due to ctx 
lock, id=1878testRequest001



MP **
MP This email and its attachments are intended for the above 
MP named only and may be confidential.  If they have come to 
MP you in error, you must take no action based on them, nor 
MP must you copy or show them to anyone; please reply to this 
MP email and highlight the error.
MP Security Warning: Please note that this email has been 
MP created in the knowledge that the internet email is not a 
MP 100% secure communications medium.  We advise that you 
MP understand and observe this lack of security when emailing us.
MP Viruses:  Although we have taken steps to ensure that this 
MP email and attachments are free from any virus, we advise 
MP that in keeping with good computing practice the recipient 
MP should ensure they are actually virus free.
MP If you have received this email in error please notify:
MP [EMAIL PROTECTED]
MP **



---
This SF.Net email is sponsored by: INetU
Attention Web Developers  Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user





---
This SF.Net email is sponsored by: INetU
Attention Web Developers  Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


Re[2]: [JBoss-user] Unable to passivate due to ctx lock

2003-06-25 Thread Alexey Loubyansky
Magesh,

I think, it is a bug in JBoss.

alex

Wednesday, June 25, 2003, 3:08:45 PM, Magesh Prabhu wrote:

MP Alex, I'm using BMP's.

MP The id's displayed in the warn message is valid. The record definitely exist in 
database.

MP Cheers,
MP Magesh

MP On 6/25/03 12:01 PM, Alexey Loubyansky [EMAIL PROTECTED] wrote:
Hello Magesh,

Wednesday, June 25, 2003, 1:33:27 PM, Magesh Prabhu wrote:

MP I'm getting this following warning. I went in to all my entity 
beans to check if I'm doing any naughtly stuff with entity context. 
Everything looks fine. Could anybody suggest me what could be
MP the possible reason for this warning.. 

For example, a bug in JBoss. Could you provide more info?
Are there foreign key fields mapped to CMP fields?
Are the id's in WARN's valid? meaning really exist in the database?

Thanks,
alex

MP Thanks in advance,
MP Magesh

MP WARN  [AbstractInstanceCache] Unable to passivate due to ctx 
lock, id=PROOFING
MP WARN  [AbstractInstanceCache] Unable to passivate due to ctx 
lock, id=PROOFING
MP WARN  [AbstractInstanceCache] Unable to passivate due to ctx 
lock, id=1878testRequest001



MP **
MP This email and its attachments are intended for the above 
MP named only and may be confidential.  If they have come to 
MP you in error, you must take no action based on them, nor 
MP must you copy or show them to anyone; please reply to this 
MP email and highlight the error.
MP Security Warning: Please note that this email has been 
MP created in the knowledge that the internet email is not a 
MP 100% secure communications medium.  We advise that you 
MP understand and observe this lack of security when emailing us.
MP Viruses:  Although we have taken steps to ensure that this 
MP email and attachments are free from any virus, we advise 
MP that in keeping with good computing practice the recipient 
MP should ensure they are actually virus free.
MP If you have received this email in error please notify:
MP [EMAIL PROTECTED]
MP **



---
This SF.Net email is sponsored by: INetU
Attention Web Developers  Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


[JBoss-user] Unable to passivate due to ctx lock

2003-06-18 Thread Davide Pozza

Can anyone tell me the meaning of this messages?

[...]
17:04:38,714 WARN  [AbstractInstanceCache] Unable to passivate due to
ctx lock, id=[.4228.]
17:04:39,020 WARN  [AbstractInstanceCache] Unable to passivate due to
ctx lock, id=[.46.]
17:04:39,727 WARN  [AbstractInstanceCache] Unable to passivate due to
ctx lock, id=[.937.]
[...]

Thanks!

Davide






signature.asc
Description: PGP signature


Re: [JBoss-user] Unable to passivate due to ctx lock

2003-06-18 Thread Alexey Loubyansky
The instances are locked and can't be passivated (evicted from the
cache). Could you provide deployment info on the entities that can't be
passivated?
Specifically, do you have foreign keys mapped to CMP fields?

alex

Wednesday, June 18, 2003, 6:13:39 PM, Davide Pozza wrote:


DP Can anyone tell me the meaning of this messages?

DP [...]
DP 17:04:38,714 WARN  [AbstractInstanceCache] Unable to passivate due to
DP ctx lock, id=[.4228.]
DP 17:04:39,020 WARN  [AbstractInstanceCache] Unable to passivate due to
DP ctx lock, id=[.46.]
DP 17:04:39,727 WARN  [AbstractInstanceCache] Unable to passivate due to
DP ctx lock, id=[.937.]
DP [...]

DP Thanks!

DP Davide



---
This SF.Net email is sponsored by: INetU
Attention Web Developers  Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user