Rajan,
See section 9 of the EJB 1.1 spec for a pciture which will be easier to
understand then my description.
If you imagine the primary key of that entity bean being a String with a
value of "1" there is only one 'entity' or what the spec calls EJBObject
for the value of "1". There would only be one row in the database which
represents that value. However, depending on the app server, there can be
multiple physical bean instances which represent that single EJBObject for
"1". The container will use the RDBMS to synchronize the data.
However this does lead to a phenomenon called a "Local Diamond". Whereby
two instances which represent the same value, or EJBOBject can become
inconsistant. As of EJB 1.1 it is the role of the container to assure local
diamonds are resolved.
Did that make it clearer?
Dave Wolf
Internet Applications Division
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rajan Kashyap
> Sent: Friday, September 01, 2000 12:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Transaction
>
>
> Hi Dave,
> I didn't get the exact meaning of
> "there can be two physcial instances of a single
> EJBObject of "id" which is
> causing the local diamond to form."
>
> Can you please elaborate a bit more..
>
> Thanks,
> Rajan
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
> Sent: Thursday, August 31, 2000 6:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Transaction
>
>
> It appears you have a somewhat off topic version of a local
> diamond forming.
> Here is the issue.
>
> methodA() {
> eb1 = ebhome.findByPK(id);
> // container calles ejbLoad() loading 111
> eb1.setXXX(222);
> // set is called on eb1 but since we are in tx
> // the container fails to call ejbStore() waiting for a
> // tx boundry. Performance enhancement.....
> System.out.println(eb1.getXXX()); // returns 222
> // reading 222 from instance level data.
>
> // just tried this after my original post
> eb2 = ebhome.findByPK(id);
> // container calls ejbLoad() loading 111 as this
> is what is
> // in the database as eb1 never had ejbStore()
> called on it
> System.out.println(eb2.getXXX()); // returns 111
> - PROBLEM
> // reading 111 from instance level data
>
>
> return methodB(id);
>
> Remember there can be two physcial instances of a single EJBObject of "id"
> which is causing the local diamond to form. The container should
> be keeping
> track of every instance of an EJBOBject for id and assuring no diamond
> forms. In this case, the container should know a setXXX method was called
> and ejbStore() is yet to be called, so when findByPrimaryKey() causes the
> ejbLoad(), the container should force eb1 to call ejbStore() first to
> maintain consistancy.
>
> The diamond is now compounded because eb1 and eb2 have differing
> states for
> XXX. If the container calls store() on eb1 then eb2 the value will rever
> back to 111. Seems like 1) The container should have detected
> this diamond
> and 2) its a good reason for optimistic locking :)
>
> Just my read on whats happening. Any other ideas anyone? Ive not seen a
> diamond like this one before, so Im not 100% sure of my diagnosis but it
> makes sense. The part I dont understand is why there was no
> locking issue.
> That could only happen with eb1 and eb2 used the same connection? That
> would be kinda odd too......
>
> Dave Wolf
> Internet Applications Division
> Sybase
>
>
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jerson Chua
> > Sent: Thursday, August 31, 2000 10:12 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Transaction
> >
> >
> > Hi Dave...
> > The Session bean is stateless. The Entity bean is bean managed.
> > The entity bean is
> > properly implemented (ejbload and ejbstore).
> > All methods' transaction attribute are set to requires (this is
> > tentative), Isolation
> > level is set to serializable.
> >
> > here's a pseudo code
> >
> > // eb.xxx's original value is 111
> >
> > class StatelessSession {
> >
> > methodA() {
> > eb1 = ebhome.findByPK(id);
> > eb1.setXXX(222);
> > System.out.println(eb1.getXXX()); // returns 222
> >
> > // just tried this after my original post
> > eb2 = ebhome.findByPK(id);
> > System.out.println(eb2.getXXX()); // returns
> 111 - PROBLEM
> >
> > return methodB(id);
> > }
> >
> > methodB(id) {
> > eb3 = ebhome.findByPK(id);
> > System.out.println(eb3.getXXX()); // returns
> 111 - PROBLEM
> > return eb3.getYYY(); // return a value object
> > which contains subset of the entity
> > bean's atrributes
> > }
> > }
> >
> > Is it because the isolation level is serializable? I think the
> > change made in methodA
> > should reflect in methodb since both methods are under the same
> > transactional context.
> >
> > Am I missing something? please guide me.
> >
> > thanks in advanced.
> > Jerson
> >
> >
> > --- Dave Wolf <[EMAIL PROTECTED]> wrote:
> > > Can I get a little better description? Is this BMP or CMP? Is
> > methodA()
> > > calling methodB() or is the client calling methodB() right
> > after methodA().
> > > What Tx level are both beans set to? I assume we have a
> > session bean which
> > > contains methodA() and methodB()? Stateful or stateless?
> > >
> > > Dave Wolf
> > > Internet Applications Division
> > > Sybase
> > >
> > >
> > > > -----Original Message-----
> > > > From: A mailing list for Enterprise JavaBeans development
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jerson Chua
> > > > Sent: Thursday, August 31, 2000 5:45 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Transaction
> > > >
> > > >
> > > > Hi...
> > > > I've a methodA which modifies the value of an entity bean. After
> > > > the modification is
> > > > performed, a methodB is called which finds for the same entity
> > > > bean and retrieves the
> > > > modified attributes. My problem is the changes made on methodA
> > > > does not reflect to the
> > > > entity bean in the methodB.
> > > >
> > > > thanks in advanced.
> > > >
> > > > Jerson
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! Mail - Free email you can access from anywhere!
> > > > http://mail.yahoo.com/
> > > >
> > > > ==================================================================
> > > > =========
> > > > 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".
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Mail - Free email you can access from anywhere!
> > http://mail.yahoo.com/
> >
> > ==================================================================
> > =========
> > 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".
>
>
===========================================================================
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".
