Start with the fact that the bank unit test deadlocks and the server is
spewing tons
of messages at info level to the console:
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 is full
(10/10)!
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 is full
(10/10)!
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [10/10/10]
waiting for a free object
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [10/10/10]
waiting for a free object
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [9/10/10]
returned object org.jboss.pool.connector.jdbc.JDBCManagedConnection@7124
af to the pool.
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [8/10/10] gave
out pooled object: org.jboss.pool.connector.jdbc.JDBCManagedConnect
ion@7124af
[DefaultDS] Pool
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [8/10/10]
returned object org.jboss.pool.connector.jdbc.JDBCManagedConnection@44cb
be to the pool.
[Default] local transaction committed
Now its not clear if the test is failing because it is taking to long to run
due this absurd level
of logging or there is another problem. David, look at the bank test and fix
the logging.
----- Original Message -----
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 6:01 PM
Subject: [JBoss-dev] jca changes & loaders
> It looks like the recent jca & datasource loaders have introduced
> inconsistency in the transaction integrety of the entity system.
>
> I have not yet been able to track this down, but based on an application
> that was working the day before yesterday, which is now non-functional
after
> more than one run, I would guess that there was a change between now and
> then that has broken something.
>
> I am seeing problems commiting transactions that invole entity beans.
Where
> a client calls a method, which updates a field, sets a modified flag.
> Sometimes the isModified() method will be called, sometimes it won't.
There
> are a few different beans getting called in a specific order, but I am not
> seeing some of the latter JDBCCommand* logs showing that the database is
> actually getting updated.
>
> My application has not changed and will appear to function with small
> message quantities (1) the first time. After running it again it will not
> work, even though the functionality is performed, the database just never
> gets up dated and thus my clients are left in the dark (pooling, waiting
for
> the dogs...).
>
> I think it would be a really good idea if we could stabale and branch a
2.6
> before any other changes are added. 2.5 (or pre-3.0 as it is called) is
> much, much better than 2.4... if we would stop breaking things trying to
> make it even better.
>
> Personally I would like to see this happen... so I could stop chasing
> around bugs that break my app and actually start working on other JBoss
> bits (like documentation of the build system, integration of the testsuite
> and other such things).
>
> JBossMQ has come leaps and bounds, so has the locking system. Lets tidy
up
> what we have then branch and keep going for full RH in 3.0!
>
> It is nice to troll through the code, but I ernestly just want something
> working. I have been playing "chase the bug" for over a month now. It is
> getting closer...
>
> If someone knows what is wrong with the tx stuff please let me know. My
> guess is that David might have a clue =P Or I guess I could have broken
> something, but I don't think I did.
>
> =|
>
> --jason
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
