EJB 2.1 does not save state through method calls in jboss 6.3

Question

We are in the process of moving from jboss 4 to jboss 6. Out has a ton of EJB 2.1 beans. After we deployed the application in jboss 6, beans stopped saving state when the method was called.

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

Edit: 2015.08.04

Bean: stateful

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

Any guidance or direction from your experience will be sufficient.

Additional Information

Scenario: A user updates an employee record.

The system has an AbstractController that does single-entry updates to records. The controller looks at the bean and retrieves a handle to it. Then, using reflection, it extracts the method names. Then sets the "isDirty" flag to true (installer inside the bean)

The controller then repeats the method names, updating each field, invoking the EJB store method. Inside the repository method, the "isDirty" flag is checked before the update statement is run.

In jboss 4, this flag remains as “true”, but when we switched to 6, this flag began to return to false.

FYI: This is an outdated source, and I really want me to be able to change the logic, but I can't.

Update: 2015.08.04: 3pm

I set a breakpoint in ejb and passivate activation methods. beans are passivated immediately after their activation. continuing my investigation. This thread will be updated.

Update: 2015.08.20 I built a sample application in accordance with the EJB specification and launched it in both jboss 5.1 and 6.3

Two copies were identical. between method calls, the 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 

I dug further, and I read it

"The bean provider can use instance variables to store values ​​that depend on the constant state of the entity bean, although this is not recommended. The bean provider should use the ejbLoad method to re-synchronize the values ​​of any instance variables that depend on the entity bean s persistent state. In general any fake state that depends on the constant state of the bean must be recounted 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 store any particular value from one call to another - if that happens, it is only because of a particular implementation or by accident.

Answer 1

After a while, I found out the reason for this behavior.

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

What is the commit option? This is the control that we have in the entity beans state at the time the transaction is committed.

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

Based on migration guide for 6.3

"In JBoss EAP 5.x, it was also possible to configure the caching, merging, commit, and interceptor stack. In JBoss EAP 6, this is no longer possible. There is only one implementation that is similar to the transaction instance policy with commit-option C"

Thanks guys for all the support. Hope my question helps other noobs stuck in a similar issue. world