EJB 2.0 introduces the concept of local interfaces and pass-by-reference semantics for intra-vm calls involving local interfaces.
Now if a CMP field (on a EJB 2.0 entity bean) is mutable, the question I have is as follows: "Would you want to persist changes made to this mutable CMP field without calling the entity bean's "set" accessor?" I'll explain with an example. The mutable CMP field is assumed to be a "java.sql.Timestamp". Now if a session bean gets this CMP field value from the entity bean's local interface [via the entity bean's "get" accessor], and modifies the Timestamp object by calling the "Timestamp.setTime(long)" should the entity bean persist the changes even though the "set" accessor for this CMP field has never been called? The arguments for doing this (i.e. the entity should persist the change to the datastore) is that pass- by-reference semantics are used here with all the support arguments in PbR's benefit. (Some of the "for" and "against" arguments are repeated in a previous post I sent: http://archives.java.sun.com/cgi-bin/wa?A2=ind0110&L=ejb-interest&P=R19789) The arguments for not doing this: - It allows the EJB developer to have a consistent view of immutable and mutable CMP fields (since most of the CMP fields are most likely immutable such as ints or Integer, Long, Float, String etc). - Allows the EJB developer to expose certain CMP fields as read-only fields - One of our R&D guys (thanks Steven Shaughnessy) has this to say: "There are subtleties. The spec requires that finders return results that reflect any edits made to entities in the same tx. Now to guarantee this with what you propose, I would have to ask the container for all entities read in that transaction and scan their contents for mutable field changes every time a finder is called. This would be slow." So, the question now is what do EJB developers prefer? Going through the spec did not answer my question (maybe I just missed it - in which case - a pointer in the right direction would be appreciated). -krish =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
