[JBoss-user] [Persistence & CMP/JBoss] - Re: Unable to passivate due to ctx lock
Does anyone at JBoss want to comment on this bug? I can supply a test case that replicates it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875260#3875260 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875260 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Re: Unable to passivate due to ctx lock
OK, I've have managed to write a generic test case that can be used to prove that a CMP entity's attributes are rendered empty by the Commit Option D refresh thread even if you do not call the a find() method a second time. Using a simple servlet (for want of a better way to talk to the EJBs) I first connected my servlet directly to a CMP entity bean. The entity bean transaction demarcation was set to RequiresNew. In-between setting the attributes of the entity I suspended the current thread. This allowed the thread that controls the Commit Option D that controls the cache to perform a flush(). I then tested the values of the attributes that I had just set... and they were fine. Not a problem. Next I introduced a session bean to act as a processor/proxy for the entity bean. The transaction demarcations were set to Required for the Entity bean, and RequiresNew for the session bean. The processor had a createEntity() method that would create a new entity instance and then start setting the values of the new entity's attributes. After setting a couple of attributes I again suspended the current thread to allow the flushing of the cache to take place. When I inspected the values of the attributes I had just set, they were empty! The session bean had not performed anymore lookups or called anymore finder methods, and yet the entity it was working with had been completely reset. This doesn't appear to be a particularly robust feature of JBoss, but it may be that I am choosing the wrong settings somewhere and would appreciate a little investigation into this matter. I have an EAR file available that can be deployed to show this bug in action, but who do I submit it to? Cheers, Carl. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3874893#3874893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3874893 --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Re: Unable to passivate due to ctx lock
Actually I managed to reproduce the problem even after removing the relationship (i.e. only setting fields that were not part of the relationship), so this is not the reason at all. Please ignore my last post. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3874441#3874441 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3874441 --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Re: Unable to passivate due to ctx lock
I've reviewed our code and the problem is occuring because we are defining the properties of an Entity as a one-to-many relationship between the Entity CMP bean and EntityProperty CMP beans: | | | Order-OrderProperty | | property-associated-with-order | Many | | |OrderPropertyEntity | | |orderEntity | | | | | order-has-properties | One | |OrderEntity | | |orderProperties |java.util.Set | | | | | Within our transaction we hold the reference to the OrderEntity bean, but not the OrderPropertyEntity beans, and it seems as if the latter are being flushed when the option-D refresh thread is triggered. That leaves the OrderEntity bean with references to empty OrderPropertyEntity beans. (The JBoss documentation says that option D does not satisfy the EJB spec - is this why?) Any ideas as to how we can work around this? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3874436#3874436 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3874436 --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Re: Unable to passivate due to ctx lock
Brilliant, thankyou! I will go and examine our code and find out if & where the finder is being called again within the transaction that is persisting to the database. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3874057#3874057 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3874057 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Re: Unable to passivate due to ctx lock
Does anyone from JBoss actually read these forums? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3873901#3873901 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3873901 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Unable to passivate due to ctx lock
Hi, We are having a problem using commit option D in that the thread that periodically flushes the cache seems to be leaving us with unpopulated entities if an entity is being updated at the time of the flush. Unfortunately I posted on the wrong topic, but the link to all the info I posted so far is here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=59610 Thought it best to move it over to this topic as it is more appropriate.[/url] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3873719#3873719 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3873719 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB/JBoss] - Re: Deja Vu.... Unable to passivate due to ctx lock
A bit of further testing on JBoss 4.0.1 revealed that this problem still occurs, but It seems it's not just limited to the one entity being updated by my test class. Our decision to use Commit Option D and QueuedPessimisticEJBLock might have something to do with it. The error seems to occur more often in JBoss 4.0.1 than it did in 3.2.5. Here's an example of where the BeanLockManager takes out a lock on the InstrumentPriceEntity EJB, the AbstractInstanceCache tries to preload the bean in the cache (causing the error) and then the lock is released by the BeanLockManager. This explains why we are seeing some strange behavior. The locked version of the entity is what gets updated and sent via JMS. The version in the cache is left empty, because the AbstractInstanceCache couldn't preload it, therefore the next time our application tries to via that entity, it sees an empty version. Needless to say the affected entity is invalid in this state which causes a great deal of havoc. We can't give JBoss sole access to the database, so commit option A is not an option. Is there any way we can change the locking mechanism to avoid this? 17:04:14,294 TRACE [BeanLockManager] Added ref to lock: [EMAIL PROTECTED], bean=InstrumentPriceEntity, id=1, refs=2, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=, BranchQual=, localId=], synched=null, timeout=5000, queue=[] 17:04:14,294 TRACE [InstrumentPriceEntity] Preloading data: entity=InstrumentPriceEntity pk=2614 cmpField=manualMaxSellAutoExec2 17:04:14,294 WARN [AbstractInstanceCache] Unable to passivate due to ctx lock, id=1 17:04:14,294 TRACE [InstrumentPriceEntity] Preloading data: entity=InstrumentPriceEntity pk=2614 cmpField=manualMaxBuyAutoQuote1 17:04:14,294 TRACE [BeanLockManager] Remove ref lock:[EMAIL PROTECTED], bean=InstrumentPriceEntity, id=1, refs=1, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=, BranchQual=, localId=], synched=null, timeout=5000, queue=[] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3873598#3873598 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3873598 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB/JBoss] - Re: Deja Vu.... Unable to passivate due to ctx lock
I have performed some testing on Gavin's system using an application that
performs alot of UPDATEs on a single entity. It basically sets and unsets a
ReservedBy field, as shown in the logs below.
Eventually one of the updates appears to collide with the cache's timer process
that is set by the configuration parameter. The cache
seems to be trying to reload the bean whilst the UPDATE process still has a
lock on it, or vice versa.
This seems to be an ineffeciency of the JBoss cache that needs addressing.
Here are the Log4j logs. My comments are in brackets {}.
{Here's an UPDATE performing smoothly...}
15:17:06,003 DEBUG [JDBCStoreEntityCommand.BorisOrderEntity] Executing SQL:
UPDATE BorisOrder SET ReservedBy=? WHERE OrderId=?
15:17:06,003 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#reservedBy] Set
parameter: index=1, jdbcType=VARCHAR, value=testuser
15:17:06,003 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#orderId] Set
parameter: index=2, jdbcType=INTEGER, value=59856
{Now the cache refresh kicks in, but the update still has the lock?...}
15:17:06,050 WARN [AbstractInstanceCache] Unable to passivate due to ctx lock,
id=59856
15:17:06,128 DEBUG
[JDBCFindByPrimaryKeyQuery.BorisOrderEntity#findByPrimaryKey] Executing SQL:
SELECT t0_BorisOrderEntity.OrderId FROM BorisOrder t0_BorisOrderEntity
WHERE t0_BorisOrderEntity.OrderId=?
15:17:06,128 TRACE
[JDBCFindByPrimaryKeyQuery.BorisOrderEntity#findByPrimaryKey] Set parameter:
index=1, jdbcType=INTEGER, value=59856
15:17:06,128 TRACE [JDBCStoreManager.BorisOrderEntity] RESET PERSISTENCE
CONTEXT: id=59856
15:17:06,128 TRACE [ReadAheadCache.BorisOrderEntity] load data:
entity=BorisOrderEntity pk=59856
15:17:06,128 TRACE [ReadAheadCache.BorisOrderEntity] No preload data found:
entity=BorisOrderEntity pk=59856
15:17:06,128 TRACE [JDBCEntityBridge.BorisOrderEntity] Default eager-load for
entity: readahead=null
15:17:06,128 DEBUG [JDBCLoadEntityCommand.BorisOrderEntity] Executing SQL:
SELECT {snip! params removed for brevity} FROM BorisOrder WHERE (OrderId=?)
15:17:06,144 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#orderId] Set
parameter: index=1, jdbcType=INTEGER, value=59856
15:17:06,144 TRACE [JDBCCMRFieldBridge.orderProperties] Read ahead cahce load:
cmrField=orderProperties pk=59856
15:17:06,144 TRACE [ReadAheadCache.BorisOrderEntity] load data:
entity=BorisOrderEntity pk=59856
15:17:06,144 TRACE [ReadAheadCache.BorisOrderEntity] No preload data found:
entity=BorisOrderEntity pk=59856
15:17:06,144 DEBUG [JDBCLoadRelationCommand.BorisOrderEntity] load relation
SQL: SELECT OrderPropertyId FROM BorisOrderProperty WHERE (OrderEntity=?)
15:17:06,144 TRACE [JDBCCMP2xFieldBridge.BorisOrderPropertyEntity#orderId] Set
parameter: index=1, jdbcType=INTEGER, value=59856
{Danger over. Next UPDATE proceeds as planned...}
15:17:06,144 DEBUG [JDBCStoreEntityCommand.BorisOrderEntity] Executing SQL:
UPDATE BorisOrder SET ReservedBy=? WHERE OrderId=?
15:17:06,160 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#reservedBy] Set
parameter: index=1, jdbcType=VARCHAR, value=
15:17:06,160 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#orderId] Set
parameter: index=2, jdbcType=INTEGER, value=59856
{And the next one too, etc, etc...}
15:17:06,191 DEBUG [JDBCStoreEntityCommand.BorisOrderEntity] Executing SQL:
UPDATE BorisOrder SET ReservedBy=? WHERE OrderId=?
15:17:06,191 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#reservedBy] Set
parameter: index=1, jdbcType=VARCHAR, value=testuser
15:17:06,191 TRACE [JDBCCMP2xFieldBridge.BorisOrderEntity#orderId] Set
parameter: index=2, jdbcType=INTEGER, value=59856
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3873582#3873582
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3873582
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
