Hi Krishnan, I know this was a question for bean developers, but will you take an answer from MVCSoft (developer of EJB 2.0 persistence)? This is a non-issue. See 10.3.3:
"The get accessor method for a cmp-field that corresponds to a dependent value class returns a copy of the dependent value class instance. The assignment of a dependent value class value to a cmp-field using the set accessor method causes the value to be copied to the target cmp-field." And of course, primitive types are immutable anyway. Anyway, the intent of the spec is clear. -Daniel O'Connor On 1 Nov 01, at 11:13, Krishnan Subramanian wrote: > 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". > =========================================================================== 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".
