-
1. Re: ejbStore() called excessively
juha Dec 16, 2002 5:14 AM (in response to iansdad)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. -
2. Re: ejbStore() called excessively
iansdad Dec 16, 2002 1:03 PM (in response to 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 -
3. Re: ejbStore() called excessively
juhalindfors Dec 20, 2002 12:20 PM (in response to iansdad)
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.