Hi Simon
Oh yes it does ;-)
You're right, when you write your CMP bean you don't have to worry about
commit options nor OR mapping. But then that's not what I was banging on
about. Aaravind's Session bean, that does the bulk update, is very much tied
to the OR mapping - which is 100% dependent on the *implementation* of OR
mapping provided by the container. That is not a part of either the EJB spec
nor the public interface of the container so that, as I said, should the
container implemented decide to change the OR mapping using by CMP then
Aaravind's session bean is broken. Change the container (something you could
do with jBoss) and the session bean is broken. Port to another appserver and
the session bean is broken.
So just to clarify. Using CMP and then directly accessing the database
generated by the jBoss container DOES make the
bean depend on JBoss' CMP implementation.
The best solution to Aaravind's problem is not to use CMP.
Edward
-----Original Message-----
From: Bordet, Simone [mailto:[EMAIL PROTECTED]]
Sent: 14 December 2000 09:54
To: 'jBoss'
Subject: RE: [jBoss-User] Entity Bean becoming Dirty..
Hey Edward,
the commit option is in the EJB spec, so all conforming containers support
it.
When you write a CMP bean, you don't have to care about commit options or OR
mapping, the containers does it for you.
The Aravind's case is quote common and it is solved by setting commit option
C. Doing this you don't take advantage of any JBoss feature; if we decide to
change CMP implementation, your bean will work anyway.
But of course you are right that there is a porting work to do to port the
bean to another container such as WL: you have to specify the commit option
C in its configuration file.
Just wanted to clarify that specifying the commit option does not make the
bean depend on JBoss' CMP implementation nor to a particular feature of
JBoss' container. The bean is not tied to the container at all. This is
because commit option is specified in the EJB spec.
Simon
> Hi Simone
>
> If you write your code to take advantage of a) an
> implementation detail of
> the underlying middleware (in this case the precise detail of
> how CMP works
> in jBoss, don't forget CMP is *not* tied to being a
> relational mapping only,
> let alone a standardised relational mapping) and you take
> advantage of a
> feature specific to a particular container (using the commit
> option set in
> jboss.xml) then you are leaving yourself open to the
> container developer
> quite validly changing their implementatio of CMP, you are also tying
> yourself to that particular container.
>
> Edward
>
> -----Original Message-----
> From: Bordet, Simone [mailto:[EMAIL PROTECTED]]
> Sent: 13 December 2000 16:09
> To: 'jBoss'
> Subject: RE: [jBoss-User] Entity Bean becoming Dirty..
>
>
> Hey Edward,
>
> > And further, if the jBoss CMP mechanism is changed (and
> > there's no reason
> > why it shouldn't be, it's implementation detail you shouldn't
> > be looking at)
> > or you change the container - all your code is broken.
>
> Don't follow. Which code is broken ? Can you post an example ?
>
> Simon
>
> > -----Original Message-----
> > From: Bordet, Simone [mailto:[EMAIL PROTECTED]]
> > Sent: 13 December 2000 15:28
> > To: 'jBoss'
> > Subject: RE: [jBoss-User] Entity Bean becoming Dirty..
> >
> >
> > Hey,
> >
> > Aravind, you have to use commit option B or C for your entity beans.
> >
> > What suggested by Edward won't work if you're using CMP, because the
> > container does not ask to a CMP bean if it's changed to
> > decide to reload it
> > from the DB.
> >
> > Commit option is set in jboss.xml
> >
> > HTH,
> >
> > Simon
> >
> > > Hi Aravind
> > >
> > > Are you using CMP ? If so then you shouldn't really be
> accessing the
> > > database directly - it's "implementation detail" of how jBoss
> > > happens to
> > > implement CMP. Also you have problems like you describe.
> > >
> > > Consider using BMP if you want complete control over the
> db and the
> > > persistence mechanisms used by your beans.
> > >
> > > Edward
> > >
> > > PS
> > >
> > > Here's a pseudo-code kludge for CMP - very horrible and very
> > > inefficient but
> > > the only way I know you could even begin to do it with CMP ;-)
> > >
> > > mySessionBean::doBulkUpdate()
> > > {
> > > do bulk update
> > > get home interface
> > > for each modified entity
> > > home.findbyPrimarykey();
> > > entity.markDirty();
> > > }
> > >
> > > -----Original Message-----
> > > From: Aravind Ajad Y [mailto:[EMAIL PROTECTED]]
> > > Sent: 13 December 2000 14:37
> > > To: [EMAIL PROTECTED]
> > > Subject: [jBoss-User] Entity Bean becoming Dirty..
> > > Importance: High
> > >
> > >
> > > Hi All,
> > >
> > > I am having a situation where I am using an entity bean is
> > > used to represent
> > > a row in the database.
> > > I also have another situation where I have to update multiple
> > > rows in single
> > > transaction. Since it
> > > bulk update, I am using a stateless session bean to call the
> > > update query.
> > > Now since the database
> > > is updated by Stateless Session Bean the data hold by the
> > > entity bean became
> > > dirty. How can I update
> > > the data in the entity beans that are dirty.
> > >
> > > regards,
> > > Aravind.
> > >
> > >
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
> > >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
