Daniel, Thanks for the response - and it was pretty much what our R&D guy said as well. But the spec could be more verbose in this (mutable, immutable) respect because:
<spec 10.3.3> A dependent value class is a concrete class. ... ... A dependent value class must be serializable. </spec 10.3.3> In which case immutable classes like "java.lang.Integer" "java.lang.Float" "java.lang.String" (and Long, Double etc) qualify as dependent value classes as well (they are concrete classes and they are Serializable). And these are used more frequently than primitives (int, float etc) in my opinion (comments?) because of their ability to hold null values, increased flexibility in manipulating them and conversions to different formats. This implies that they will have to be copied (since they are immutable - it doesn't really matter anyways) by a cmp entity bean before being returned to the caller. I'm repeating myself from a previous post here - a good marshaling engine (like the one in VisiBroker) should detect the use of immutable objects (which we do) and avoid unnecessary argument copying thus enhancing performance. But how many other marshaling engines do so? Doesn't this also negate some of the (supposed ;) performance benefits of PbR semantics when using a collocated cmp entity and session bean? And doesn't this also somewhat 'clash' with a developer's perception of PbR in the world of collocated EJBs? -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel OConnor > Sent: Thursday, November 01, 2001 4:10 PM > To: [EMAIL PROTECTED] > Subject: Re: EJB 2.0 CMP: Question for EJB developers > > > 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". > > =========================================================================== 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".
