Nasty bug with JBoss 2.4

[nuanda]

Hi all,

Noticed something troubling with 2.4 (running JVM 1.3.1 on either Win32 or Linux 2.4.x).

It is concerned with the removal of entity bean instances. Specifically, after one entity is removed that instance is being re-used for the next entity of that type created _without_ first clearing the instance variables.

This is easy to re-create...simply write an entity bean with a create method like:

/** Instance variable 'state' */
private String state = "Clean";

public Integer ejbCreate() {
System.out.println("State at instantiation: " + this.state);
this.state = "Dirty";
System.out.println("State after create: " + this.state);
return // some unique primary key;
}


If you run this test code:

TestEntity testEntityOne = this.testEntityHome.create();
TestEntity testEntityTwo = this.testEntityHome.create();


The output on the JBoss server will read:

State at instantiation: Clean
State after create: Dirty
State at instantiation: Clean
State after create: Dirty

Fine...but if you run with test code:

TestEntity testEntityOne = this.testEntityHome.create();
testEntityOne.remove();
TestEntity testEntityTwo = this.testEntityHome.create();

You get:

State at instantiation: Clean
State after create: Dirty
State at instantiation: Dirty
State after create: Dirty



YUCK!!

[nuanda]

My apologies!! Apparently this is me mis-understanding the EJB spec. Scott Stark informs me that a programmer is entirely responsible for setting all state of an EJB in ejbCreate(), instance variables may contain any data when ejbCreate() is called.

This causes a slight problem for our code as we have 'dateFrom', 'dateTo' style instance vars. In ejbCreate we call 'setDateFrom' and 'setDateTo' accessors to take advantage of the parameter validation checks in those set methods.

We had coded them to ensure that if dateTo was not null then it should only occur after dateFrom. The problem with dirty data hanging around meant that when calling setDateFrom in ejbCreate it was occasionally throwing an IllegalParamEx because dateTo was not null, given that it contained old state hanging around from the previous bean instance that happened to be before dateFrom.

I assume we will have to do:

this.dateTo = null;
this.dateFrom = null;

...kind of code right at the start of ejbCreate to clean up hang-over data.

Seems a little ick, but what're you gonna do ;-)