This ejbdoclet gives me "la puce a l'oreille".
The problem comes from ejbdoclet.
Of course.
Why can I never finish something...
The problem comes from how hashCode is calculated by ejbdoclet :
public int hashCode()
{
int _hashCode = 0;
if (_hashCode == Integer.MIN_VALUE)
{
_hashCode += this.pk.hashCode();
}
return _hashCode;
}
With _hashCode being defined as private :
private int _hashCode = Integer.MIN_VALUE;
If you change that to
transient private int _hashCode = Integer.MIN_VALUE;
The problem disappear. No need toString().
If you follow my thread, you can understand what I am talking about.
It should have been clear from the beginning :
if (problem_in_the_cache == true)
{
while (pk.getClass().getMethod("hashCode").isFuckedUp())
{
pk.getClass().getMethod("hashCode").print("BOLD ARIAL SIZE=60");
pk.getClass().getMethod("hashCode").debug();
}
}
That was a good one.
Oh yes a good one, believe me two months telling the world Cache in Jboss is
bad. Shame on me.
jboss-developement.getUser("Vincent Harcq").banish();
Vincent.
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Vincent Harcq
> Envoyé : vendredi 6 juillet 2001 9:06
> À : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] Any problems vith the cache in 2.4?
>
>
> Can you try this:
> 1. Solution 1
> Add a toString to your PK (hack entitypk.j).
> Also put your Cache size very high.
> And your overager periods very high as well.
> 2. Solution 2.
> Set your cache size to 1/1 (min/max)
>
> Let us know please.
> Vincent.
>
> > -----Message d'origine-----
> > De : [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]De la part de
> > Lennart Petersson
> > Envoyé : jeudi 5 juillet 2001 11:55
> > À : jBoss Developer
> > Objet : [JBoss-dev] Any problems vith the cache in 2.4?
> >
> >
> > 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
> >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> _______________________________________________
> 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
