Big Trouble!! Problem with finder methods.

[banigreyling]

Hi,

I use CMP on JBoss2.4.1a_Tomcat3.2.3 and MSSql Server 2000.

For this specific bean I have an additional finder method named findByAccountNo. I do not specify the where clause, but rely on JBoss's ability to figure the column name from the findBy method. If, however, I have findByPrimaryKey and findByAccountNo returning me the same object and I make changes to the one object, the changes do not reflect on the object returned by the other method. The processflow (in psuedo-code)would typically be:

1)Object a = findByAccountNo("ANACCTNO"); (Returning only one object in the collection)
2)findByPrimaryKey(new PK("ABC","ANACCTNO"));
3)a.setSomething("QWERTY");
4)Object b = findByPrimaryKey(new PK("ABC","ANACCTNO"));

Where
a.getPK.equals(b.getPK) evaluates true

**** BUT I FIND THAT ***

a.getSomething().equals(b.getSomething()) evaluates false

which IMHO is a serious BUG.

Should you go to the trouble of getting the monitor application working, you will notice that the cache for this bean have two active instances although there is only one row in the database!

I really hope someone can either proof me wrong or fix it.

Regards
Bani

[davidjencks]

Just to check, do you have equals and hashcode implemented properly for your pk object? (same constructor values ==> pk1.equals(pk2) == true, and pk1.equals(pk2) ==> pk1.hashcode() == pk2.hashcode())

[banigreyling]

I waited for this question. This is my implementation. I cannot see any problem with it, but maybee all it need is another opinion, so here it is:

public int hashCode() {
return companyCode.hashCode() + accountNo.hashCode();
}

public boolean equals(Object obj) {
if (this.getClass().equals(obj.getClass())) {
AccountHolderPK that = (AccountHolderPK) obj;
return this.companyCode.equals(that.companyCode) && this.accountNo.equals(that.accountNo);
}
return false;
}

The following test:

AccountHolderPK pk1 = new AccountHolderPK("ABC","MYACCOUNT");
AccountHolderPK pk2 = new AccountHolderPK("ABC","MYACCOUNT");
System.out.println(pk1.equals(pk2));
System.out.println(pk2.equals(pk1));
System.out.println(pk1.hashCode() == pk2.hashCode());

yields the output
true
true
true

So I think this implementation is OK. Any other suggetions?

Regards
Bani

[banigreyling]

Anyone? .... Please!!

[danch1]

Just out of curiosity, are you using commit-option A? This is the default.
If so, can you try commit-option B (change standardjboss.xml) and see if that helps, and post on this topic if it does?
Believe it or not, this will help narrow down this problem and (possibly) another.

[banigreyling]

I had no doubt that this would be a good workaround. Just to make sure I tested it and yes, with commit option B the problem seems to disapear. What actually is happenning, is the stale object get updated before participating in the request and therefore the problem is not visible.

There is not supposed to be a stale object. Seems like JBoss keeps a seperate cache for each finder method.

[danch1]

commit option B _means_ that any entity bean is updated from storage before participating in a transaction. This isn't 'hiding' the bug so much as downright avoiding it!
Last question: are you using read-ahead?
I'm already hunting this bug, so any information you can give me will help me find it.

thanks,
danch

[banigreyling]

Danch

No, I am not using Read-Ahead. I am using tuned updates though.

Thanks a lot
Bani

PS could you maybe have a look at http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=forums/ and make an informed comment. I am flying a bit in the dark there.

[banigreyling]

Any more news on this front?

[danch1]

Sorry about the delay. I'm trying to replicate this problem and I'm having trouble. Can you send me your deployment descriptors ('sanitized' to hide details of your application, if you like) via email ([e-mail])?

Also, is the code sample in your original post from a client (or servlet/JSP), or is it in a session bean?

thanks,
danch

[banigreyling]

Hi Danch

I got the source of the problem. Sorry, I should have picked this up earlier.

If I create a Primary Key object to lookup some object, all is fine. When I do a findBySomeColumn, then the container creates the primary key: all should still be fine, BUT I am using CHAR datatypes. SQLServer rightpad the data in the PK with spaces. As a result the objects evaluates to not being equal. The Question that now remain is: Should the container trim the string values, or should equality be simulated by the PrimaryKey object's equals method? I think the latter option is more practical, as someone might want the spaces. Maybe a deployment option to trim string values?

Thanks
Bani

[danch1]

Glad to hear you've found the problem. I agree, the PrimaryKey needs to do the trimming: as you say, the spaces may be important.