Commit option A causing issues with cache not updating

[cvandyck]

Hello

For the purpose of this example, assume I have two entities, X and Y, where Y has a fk mapping to X such that:

Entity X:
public abstract Y getY();
public abstract void setY(Y y);

and

Entity Y:
public abstract java.util.Collection getXs();
public abstract void setXx(java.util.Collection xs);

I have management routines with session facades (Required transaction type) for both types of entities, which appear to be working fine. I can make updates to both types X and Y and upon re-editing the entities I see the changes reflected.

However, using Commit option A with MS SQLServer as my data store, I am seeing an odd behavior:

1) I edit entity Y1, changing all of the CMP fields using a session facade with Required transaction attribute. I check the database to verify that the data has been updated on the database and it has.

2) In a future thread I obtain a reference to an instance of X which has a non-null rerference to Y1 using xHome.findByPrimaryKey(id).

3) calling xEntity.getY() results in an instance of Y for which all of the CMP fields are old and out of date (before step 1). There is only one instance of Y in the database, and looking at the primary key of Y verifies that I'm not looking at a different entity.

Now, if I change my commit option to type B, then this oddness goes away. This leads me to believe it's an issue with caching at the CMP/EJB level.

Strangely, though, I've been using jboss3.2.3 for quite some time now and have not seen this behavior before. Any ideas on what I might be doing wrong? I don't want to use commit option B because it's just too slow.

Any help appreciated.
Collin

env:

MSSQLServer 2000
Commit option A
JBoss 3.2.3, Windows XP

[cvandyck]

Update: I tried running the application on JBoss 3.2.6, but the same problem persists.

Any ideas?

[aloubyansky]

What have you changed in the container/bean configurations?

[cvandyck]

Alex,

The problem ended up being my own fault (of course), as it usually does :)

The problem was that we had created our MSSQLServer tables manually, as our application is already deployed to multiple clients and we can't depend on the container to re-create tables from scratch every time.

Our entity primary keys are all character string based, usually 32 characters. In this one instance we had manually inserted a row into the database with primary key 'ROOT'. However, we had defined the column as char(32), which mean that SQLServer padded the rest of that particular record with whitespace.

That whitespace was what ultimately was causing our problems. The strange thing is that

xHome.findByPrimaryKey("ROOT") found the entity successfully when actually its primary key was "ROOT (+ 28 space characters)".

Is that part of the specification that I had not understood previously? I would think that it should throw a FinderException in this case.

Collin

[aloubyansky]

That's a feature of the database/driver. You can try it yourself with JDBC.

[cvandyck]

You're right alex. Thanks.