Unable to passivate due to ctx lock

[hswac]

Hi,

we've problems with stateful session beans, user transactions and passivation.

When a stateful session bean instance is part of a user transaction and JBoss
tries to passivate this bean we got the warning "Unable to passivate due to ctx lock". This is ok, because beans cannot be passivated when they are part of a transaction. But when I access the bean afterwards, JBoss tries to activate the bean but can't do this because the bean wasn't passivated at all.
We got the following exception:

java.rmi.NoSuchObjectException: Could not activate; failed to restore state; Cau
sedByException is:
C:\Programme\jboss-3.2.2\server\default\tmp\sessions\MyBean-d
ruw1307-8v\druw5s8a-b5.ser (Das System kann die angegebene Datei nicht finden)

For me, this seems to be a bug in JBoss, because JBoss tries to activate a bean which was never passivated. We're using JBoss 3.2.2.

Any comments or hints? Thanks in advance.
Helmut

[adrian.brock]

It was fixed in 3.2.3

Regards,
Adrian

[hswac]

Hi Adrian,

thanks for the answer. I tried 3.2.3. But the bug was not fixed completely:

16:06:14,399 WARN [AbstractInstanceCache] Unable to passivate due to ctx lock,id=drw40msp-40
16:06:19,506 ERROR [LogInterceptor] TransactionRolledbackException in method: public abstract javax.ejb.EJBObject javax.ejb.Handle.getEJBObject() throws java.rmi.RemoteException, causedBy:
java.rmi.NoSuchObjectException: Could not activate; failed to restore state; CausedByException is:
C:\Programme\jboss-3.2.3\server\default\tmp\sessions\MyBean-drw3ajqv-2r
\drw40mvr-43.ser (Das System kann die angegebene Datei nicht finden)

I think, this corrensponds to bug 780746 reported in the bugs database.

Regards
Helmut

[adrian.brock]

The bug fix is in 3.2.3 and there are tests for this exact behaviour in the testsuite.
You have some other problem.
Try enabling TRACE logging for org.jboss.ejb.plugins so I can see what it is going on.

Regards,
Adrian

[pilhuhn]

I have seen similar things and it turned out to be a combination of not "cleaning up" and nulpointer exceptions further down in the excecution chain which triggered the TxRollback Exception.

[hswac]

Adrian, you're right, the 'unable to passivate bug' is fixed in 3.2.3.
The problem left was of some other kind.

Thanks and regards
Helmut

[jkraus]

"hswac" wrote:

The problem left was of some other kind.
...

Helmut, please could you give a hint, what was wrong in your configuration.
We also have installed 3.2.3 and now always get the warning "Unable to passivate due to ctx lock".
After a while the following exception occurs...
Do you know why?

Thanks.Juergen

...
15:16:34,698 INFO [STDOUT] MischKalkulationContrEJB.setSessionContext
15:16:34,557 ERROR [LogInterceptor] TransactionRolledbackException in method: public abstract javax.ejb.EJBObject javax.ejb.Handle.getEJBObject() throws java.rmi.RemoteException, causedBy:
java.rmi.NoSuchObjectException: Could not activate; failed to restore state; CausedByException is:
C:\jboss-3.2.3\server\default\tmp\sessions\GraphVorplanungsContrEJB-ds7hplkq-9\ds7hpy80-b.ser (Das System kann die angegebene Datei nicht finden)
at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:116)
at org.jboss.ejb.StatefulSessionContainer.getEJBObject(StatefulSessionContainer.java:620)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
...

[twgerber]

Yes - it would be helpful to know the source of your problem as I might be having the same issue. Also how did you track it down?

Thx

[jkraus]

The TransactionRolledbackException above is caused by the following situtation we have:
At the client there are lookup to two stateful session beans... bean1 and bean2. When the client exits it calls ejbRemove for bean1 and bean2.
By the way... bean1 and bean2 are passivated in this situation.
bean1 can be removed without any problem, but when removing bean2 it looks like bean2 has already been removed by the server or the application server tries to activate bean2 but bean2 has already been removed. This perhaps could be a bug: why should the server try to activate the session if it no longer exists.

I solved this special problem by removing bean2 before bean1 but I don't know why.

I have not solved the problem for "Unable to passivate due to ctx lock". It would be nice to get information about active transactions that are not closed.

Jürgen

[frodeh]

I experience something like this as well.

I am reading a text-file, and each line is parsed to update/create some CMP-beans.

If the file I read is very big, it seems to run out of memory, and the cause of this, seems to be the growing list of ctx-locks.

I see this in the event that if I touches the application.xml-file for redploying the application after the file is partially read, I get this error for each of the lines that have been read (and the CMP-bean has been updated).

I reuse the variable for the Local-interface I use fur update, an I cannot find any method to 'release' the ctx-lock. I would presume that the container should free the lock when the bean was not referenced anymore, but it doesn't seem to work well.

[stephanenicoll]

"frodeh" wrote:
I experience something like this as well.

I am reading a text-file, and each line is parsed to update/create some CMP-beans.

If the file I read is very big, it seems to run out of memory, and the cause of this, seems to be the growing list of ctx-locks.

I see this in the event that if I touches the application.xml-file for redploying the application after the file is partially read, I get this error for each of the lines that have been read (and the CMP-bean has been updated).

I reuse the variable for the Local-interface I use fur update, an I cannot find any method to 'release' the ctx-lock. I would presume that the container should free the lock when the bean was not referenced anymore, but it doesn't seem to work well.

The warning message is the same but I think it's totally different. Let's say your cache has a size of 1000 and you tries to create 5000 entity beans. When the cache is full, JBoss tries to passivate some instances to allow you to create new ones (entities 1001, 1002, etc). But the problem is that i can't passivate them because they are enlisted in the big transaction that parses your text file.

Regards,

Stephane

[frodeh]

Well, I don't see why the created instanced has this lock.

snippet from code :

while ((l=in.readLine())!=null) {
lv = parseString(lv,l);
GenericPk produkt= new GenericPk(lv.prod,lv.pvid);

//some code to see if the product is already created.
//does not involve any beans If the product isn't there, i call :

produkt=pSess.lagNyttProdukt(produkt,lv.desc);

}
in.close();

---
the pSess is an reference to another stateless session-bean that handles the creation of an product, and return with the primary key for the created product.
lv is plain java-object containg some values from the file.

In addition I have a one-to-many relation between the product, and a manufacturer, and the manufacturer-bean is also updated with a lock when I create a product.

I should think that the call to a method in pHome was a single transaction, and should free any resources afterwards. It is a staless session-bean that only returns a composite key. No reference to the created EJB.

[frodeh]

My problem is solved.
I wasn't aware of the fact that that since I started all my activity from a session-bean (stateless), all bean-activity from there became a part in the same transaction.

I simply cannot use a session-bean with required transaction to update 30.000 instances.

I have two possible solutions :
1. Make the session-bean from which all starts a non-transactional bean.
2. Use SQL to du the updates.

Since I update/create entities with relations, and the 'one' -end of the relation is automatically stored for each update/create of an instance in the 'many'-end, I choose to use SQL.

I have followed the gangster-sample when creating my relations, and this unexpected behavior of re-saving the 1-entity each time was really a setback for me. I simply cannot use CMP-beans to do mass-updates/creatins.

[sunstarnova]

I have a similar problem, but base on TimdBeans. I also get Rollbacks and even worse the TimedBean will no longer execute correctly!
I guess it mayb could be the same problem. My question is: How canI see if my transaction will be passivated (I'v got an export service and may send 0 to 1500 files via FTP depending on the working queue)?
The sending is done in a session bean that will be called by the timed bean (stteless). May that be the same problem?
I also get the "Unable to passivate due to ctx lock" message in my log - and a Rollback cause by a CMP update (I save the date of the last export run in a database, so it seems to fail the next iteration).

Thanks,
Dennis