Ok, please dont hang me, not now :-) I know that i'm not given you much details and no
clean and short testcase but i still wanted to trigger your brains to give me some
advice of how to preceed my debugging.
Fact: Using CVS brancs 2.4 from 2001-07-04. CMP entity beans, commit option A, tuned
updates, using isModified() method, using EJBDoclet code generator (still on 0.95 with
some newer patches incorparated - like ejbPassivate() bug). Alwasy using a stateless
Session Bean in front of the Entity Bean. All session bean methods that will result in
a db update has TX_REQUIRED. All other session bean methods as TX_SUPPORTS. Oracle
database and standalone clients.
Problem scenario 1:
A) Populates a GUI table with data originating from a findAll().
B) User selects one row and details about that entity is looked up using a
findByPrimaryKey()
C) User change some attribute and this _IS_ stored in database
D) User returns to the GUI table wich is repopulated using a findAll() ---> Old value
is seen
E) User selects same row again details about that entity is looked up using a
findByPrimaryKey() ---> Correct vallue is seen
F) Restart client, still old value in GUI table using findAll() but correct value in
details frame using findByPrimaryKey.
G) Restarting JBoss, now correcte value in both cases.
When i'm debugging JBoss i can see that the findAll in D) is getting old values from
the cache.
If i change cache sizes to min=1 and max=1 the problem i no more! Should i take this
for a evidence of JBoss bug rather then a bug i our code?
Please note that if i'm doing a test bean and a short testcase for this scenario then
i can't reproduce the error. Which as opposed to above makes our app more guilty or?
Problem scenario 2:
A) Viewing details from an entity in a GUI.
B) Waits until the server has been idle from some hour or so.
C) Trying to view details from this same entity again ---> Now incorrect values are
seen.
This one i've not debugged att all. Guess that during B) beans are passivated due to
them being out aged. Also please not that in this case the session bean in front of
entity beans is a stateful bean.
Are there anny know problems with caches/pools in JBoss 2.4?
Are there any mysterios behavior noted by someon but not yet traced down?
Also a bit off-topic: I'm using Bugseeker to debug my code and JBoss. Running on a P3
800 with 512 in memory and it is fu...ng slow!!! What are you using as a debug tool?
I'm attaching to JBoss JVM as a remote process but still on same machine, guess i will
have better performance if Bugseeker is the one really starting JBoss, havent tried
that yet. As it is now debugging is more of a wait then really productive :-(
Please, any ideas are welcome! I will complement with more detailes as my own tests
progress. This might be what make us Go! or Die!
/Lennart
===================
Lennart Petersson
www.benefit.se/english
[EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
