EJB 2.1 doesn't preserve state across method calls in jboss 6.3

Question

We are in the process of migrating from jboss 4 to jboss 6. Out system has a ton of EJB 2.1 beans. Once we deployed the application in jboss 6, the beans stopped preserving state across method calls.

IS this normal? if not, what can be done to overcome this problem?

Edit:2015.08.04

Bean: Stateful

I wish i could share src code but, the company has very strict policies.

Any guidance or direction from your experience would suffice.

More info

Scenario: user updates a employee record.

The system has a AbstractController which does single record updates. The controller looks up the bean and retrieves the handle to it. Then, using reflection it retrieves the method names. Then sets a flag 'isDirty' to true (setter inside the bean)

The controller then iterates over the method names updating each field by calling the EJB store method. Within the store method before the update statement is run the flag 'isDirty' is checked.

In jboss 4 this flag remains as 'true', but when we migrated into 6, this flag started to reverting back to false.

FYI: This is legacy source, and i really wish i could change the logic, but i cant.

Update: 2015.08.04: 3pm

I placed a break point in the ejb activate and passivate methods. The beans are being passivated immediately after they are activated. continuing my investigation. Will keep this thread updated.

Update: 2015.08.20 I built a sample application according to the EJB spec and ran it in both jboss 5.1 and 6.3

The two instances were identical. between method calls, the entity bean loses its state

bean.doSomething();
bean.doSomethingElse();

results

setEntityContext(EntityContext ctx) invoked --- Flag Value-false
ejbCreate() invoked --- Flag Value-false
ejbPostCreate() invoked --- Flag Value-false
ejbPassivate() invoked --- Flag Value-false
unsetEntityContext() invoked --- Flag Value-false
setEntityContext(EntityContext ctx) invoked --- Flag Value-false
ejbActivate() invoked --- Flag Value-false
ejbLoad() invoked --- Flag Value-false
[EmailConfigBean] doSomething invoked.--- Flag Value Updated to-true
ejbStore() invoked --- Flag Value-true
ejbPassivate() invoked --- Flag Value-true
unsetEntityContext() invoked --- Flag Value-true
setEntityContext(EntityContext ctx) invoked --- Flag Value-false
ejbActivate() invoked --- Flag Value-false
ejbLoad() invoked --- Flag Value-false
[EmailConfigBean] doSomethingElse invoked.--- int Value Updated to-10
ejbStore() invoked --- Flag Value-false
ejbPassivate() invoked --- Flag Value-false
unsetEntityContext() invoked --- Flag Value-false

Did some further digging and i read this

"The Bean Provider can use instance variables to store values that depend on the persistent state of the entity bean instance, although this use is not encouraged. The Bean Provider should use the ejbLoad method to resynchronize the values of any instance variables that depend on the entity bean’s persistent state. In general, any non-persistent state that depends on the persistent state of an entity bean should be recomputed during the ejbLoad method."

In other words, you are responsible for setting "isDirty" to the correct state during ejbLoad. You should not expect it to retain any specific value from one call to the next – if it does, it's only because of a specific implementation or by accident.

Answer 1

After a long while, i figured out the reason for this behavior.

Basically, in jboss 6.3 they have only support for commit-option 3.

What is a commit-option? It is the control we have on the entity beans state at transaction commit time.

what is commit-option 3? "Pooled bean: At the end of the transaction, neither the instance nor its state is valid (instance will be passivated and returned to the pool). Every client call causes an ejbActivate, ejbLoad, then the business method, then ejbStore, and ejbPassivate"

based on the migration guide for 6.3

"In JBoss EAP 5.x, it was also possible to customize caching, pooling, commit-options, and the interceptor stack. In JBoss EAP 6, this is no longer possible. There is only one implementation, which is similar to the Instance Per Transaction policy with commit-option C"

Thank you guys for all the support - hope my question helps out other noobs stuck on a similar issue. peace