just another hint, maybe you already know this..
During testing for possible workarounds I ran into a test case for a class
without any relationship to other classes (no references, no foreign keys no inheritance,
as flat as it could be).
This test case works with eager-release="true" without any problem.
Maybe that the problem only occours if complex objects has to be build by OJB.
Could you (or somebody else) find out anything that helps?
Oh and you posted a sample from JBoss 3.2..1. I'm running with JBoss 3.2.2RC3
I don't know if this makes a difference for the current problem.
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
On Thu, 09 Oct 2003 15:17:24 +0200, Guido Beutler <[EMAIL PROTECTED]> wrote:
Hi Armin,
just to keep the problem clear:
If I run my standalone tescase (without any jboss around it) and set eager-release to true the problem occours too! Only one instead of 77 objects are selected. If I change to eager-release="false" all 77 objects are selected.
clear, that's why we should kick 'eager-release' out. eager-release is a work-around that does not really work. So we should try to solve the main problem, occur when run jboss with eager-release 'false' setting.
regards, Armin
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
On Wed, 08 Oct 2003 18:17:21 +0200, Guido Beutler <[EMAIL PROTECTED]> wrote:
Hi Armin,great!
took some time but I was able to build the testcase.
snip :-)
...
If I run the standalone testcase with eager-release="true" the test fails. Only one object is selected. If I set eager-release="false" everything works fine.
eager-release is the root of all evil :-) I know it's a workaround for a jboss problem. What can I do inside of jboss with my ejb's now???
I don't know if this problem is caused by jboss or by OJB. But I assume it's jboss because I never heard about problems (with connections) within e.g. weblogic.
The 'eager-release' attribute was introduced by Matthew, maybe he can sheed some light on the problem why jboss needs this special handling.
you said when set eager-release 'false' you get the following stack trace:
15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener] throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown connection1! [EMAIL PROTECTED]
at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550) ...
I looked in the source code of jboss 3.2.1 online source can be found at
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/CachedConnectionManager_8java-source.html http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/TxConnectionManager_8java-source.html
TxConnectionManager$TxConnectionEventListener.connectionClosed looks like
public void connectionClosed(ConnectionEvent ce)
00541 {
00542 log.trace("connectionClosed called");
00543 if (this.getManagedConnection() != (ManagedConnection)ce.getSource())
00544 {
00545 throw new IllegalArgumentException("ConnectionClosed event received from wrong ManagedConnection! Expected: " + this.getManagedConnection() + ", actual: " + ce.getSource());
00546 } // end of if ()
00547 //log.trace("about to call unregisterConnection");
00548 try
00549 {
00550 getCcm().unregisterConnection(TxConnectionManager.this, ce.getConnectionHandle()); }
00551 catch (Throwable t)
00552 {
00553 log.info("throwable from unregister connection", t);
00554 } // end of try-catch
00555
...
and CachedConnectionManager.unregisterConnection looks like
00248 void unregisterConnection(ConnectionCacheListener cm, Object c)
00249 {
00250 KeyConnectionAssociation key = peekMetaAwareObject();
00251 if (log.isTraceEnabled())
00252 {
00253 log.trace("unregistering connection from " + cm + ", object: " + c + ", key: " + key);
00254 } // end of if ()
00255 if (key == null)
00256 {
00257 return; //not participating properly in this management scheme.
00258 } // end of if ()
00259
00260 Map cmToConnectionsMap = key.getCMToConnectionsMap();
00261 Collection conns = (Collection)cmToConnectionsMap.get(cm);
00262 if (conns == null)
00263 {
00264 throw new IllegalStateException("Trying to return an unknown connection1! " + c);
00265 //return;//???shouldn't happen.
00266 } // end of if ()
00267 for (Iterator i = conns.iterator(); i.hasNext(); )
00268 {
00269 if (((ConnectionRecord)i.next()).connection == c)
...
Looks strange for me to throw an IllegalStateException and then catch it and log with info-level.
Next strange server log output (when run bean examples) is something like:
2003-10-08 23:22:07,782 DEBUG [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] SQL:INSERT INTO EJB_ARTICLE (ARTICLE_ID,NAME,PRICE,DESCRIPTION,CATEGORY_ID) VALUES (?,?,?,?,?)
2003-10-08 23:22:07,782 DEBUG [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] executeInsert: [EMAIL PROTECTED]
2003-10-08 23:22:07,782 DEBUG [org.apache.ojb.broker.accesslayer.StatementManager] closeResources was called
2003-10-08 23:22:07,782 DEBUG [org.apache.ojb.broker.core.PersistenceBrokerImpl] PB.close was called: [EMAIL PROTECTED]
2003-10-08 23:22:07,782 WARN [org.jboss.resource.adapter.jdbc.WrappedConnection] Closing a statement you left open, please do your own housekeeping
That's strange, because StatementManager close given statement on 'closeResources' call.
Does OJB internally open another statement and do not close, or do jboss ignore
the statement close call made by StatementManager?
Any kind of proposal are welcome!
regards, Armin
best regards,
Guido
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
