ejbStore() called excessively

[iansdad]

I'm a JDBC driver developer currently working on adding XA support to our driver. As part of the testing process, a colleague and I decided to use JBoss so I implemented a mock Banking application complete with several servlets and some EntityBean's. Much to our surprise, ejbStore() is being called, even when our beans 'getter' methods are called. For example, we have a lookup servlet that retrieves account information, which is then retrieved from the account bean and inserted into our html page. Each time a getter method of the account bean is called, the JBoss container is calling ejbStore(). I've discovered by searching the JBoss source that by implementing isModified() in the entity bean that I can eliminate the uneccessary ejbStore calls, however, this seems non-standard. Is this really a JBoss bug and if so, how are JBoss EJB developers dealing with this problem in the real world.

Or is there some other configuration related way to deal with this?

Thanks,

Bob

[juha]

It's not a bug. If you're calling a getter method it will trigger an ejbStore() even if you're just returning a value. Prior to CMP 2.0 the container had no way of automatically knowing whether your code actually modified the state -- even for a simple case of a getter. So ejbStore() is called and the CMP 1.1 engine does a comparison of the entity state to determine if values have changed or not.

JBossCMP2.0 engine allows you to mark cmp-fields as read-only. This might generate an ejbStore() callback as well (I didn't check) but the container is now in control of all your CMP field state (because of the abstract accessors to CMP fields) so it can immediately recognize a read-only field and know you had no way of modifying its state. So no actual communication with the DB is done in case of a getter call. (this was also true in JAWS CMP 1.1 engine although involved a little more work).

IsModified allows you to bypass the call to the CMP engine completely but requires you to manually keep track of your state changes. In JAWS CMP 1.1 this might have had a slight performance impact, it is most likely not necessary if you're using CMP2.0.

[iansdad]

Juha,

Thanks for the info, but I'm even more confused now! You seem to be saying that this is the normal behavior for container managed persistence (CMP), but I'm using bean managed persistence (BMP).

It does seem that JBoss could safely make a broad assumption that getter methods, certainly standard JavaBean getter methods, would never update state.

Bob

[juhalindfors]

It is normal for BMP too. In BMP you're in charge of the database communication so you can write your own checks in the ejbStore() method to make sure you don't serialize to the database unnecessarily.

> It does seem that JBoss could safely make a broad
> oad assumption that getter methods, certainly
> standard JavaBean getter methods, would never update
> state.

Well no it really can't if the implementation stays within the spec. I guess there could be a non-standard option for this for BMP but since CMP can already do the same for you, it doesn't look like it would get a lot of use. Certainly not a high priority.