Eric, One of the ideas of VOs is to use bulk gets and sets.
You are on the right track that you would need to call the setSeller() and setDescription() within the setValueObject(VO someVO). The EJB 2.0 spec mandates the use of getters and setters. <vendor> Some vendors will write to the database immediately; that is, call the ejbStore() immediately. But this call can be deferred until the end of the transaction (or until some other transaction wants to work with the same data - e.g: a finder called by another transaction) and this what we do. Thus, we can avoid the overhead of multiple ejbStore()s. In addition to this, our difference detection engine checks if fields were actually modified by the setters, and if they were not - we can avoid an unnecessary ejbStore(). This could have a lot of benefits. For example a VO could have 10 fields which represent the persistent fields in an entity bean. Some of these fields could be complex objects such as byte[] (or blobs/clobs/image etc). If a client (say a session facade) calls the setVO, this will result in 10 set....() called. That is, one on each of the persisted fields. If in actuality only two fields in the VO were modified, you have unnecessarily issued an update to the database to update the 8 fields. If using byte[] etc, this could have a significant impact on DB performance. We get around this and as mentioned above, our difference detection engine will ensure that the update issued to the database will only update the 2 changed fields. Also, there is an additional RPC cost in terms of sending a larger update statement to the database. <vendor> You are again on the right track that BMP is to be avoided. In the words of our AppServer architect, BMP is an "abyssmal compromise". But that's not the issue here. Hope this helps. -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Eric Dunn > Sent: Friday, December 21, 2001 1:22 AM > To: [EMAIL PROTECTED] > Subject: Value Object Design Pattern > > > Dear all, > > I am trying to design a large scale system with optimal EJB communication. I was >wondering with the Value Object Design > Pattern, how would a CMP 2.0 spec use the Value Object to SET the values in the >entity bean? The way I retrieve values is > exactly how WROX does it in "Professional EJB, Common EJB Design Patterns Page 520). > > There are the mapped variables which are persisted automatically by the containers >persistence engine as normal in the > main implementation class. As a change, the entity bean extends my value object >class which has a getData() method which > basically returns this.seller, this.description, etc in a class. > > This is all fine and dandy, as the Value Object is not a field managed by the bean. >But is it possible to set in the same > manner, where I send it a value object (using CMP2.0 keep in mind), and I set the >variables then inside the set method? > Should I make a method called setValueObject(ValueObject v) that calls say setSeller >and setDescription() explicitly? > Would this set off then a EJBStore after every set call then? Is there a way I could >have only one EJBStore command be > called every time I set a value object using EJB2.0? Keep in mind I'm trying to >avoid BMP. > > Warmest Regards, > Eric Dunn > > =========================================================================== > 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".
