Duh!....Sorrrryy
You could probably do the same with CMP/JAWS, correct?
bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jay
> Walters
> Sent: Tuesday, June 19, 2001 9:55 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead
> toDB corruption
>
>
> When using BMP I can put SQL anywhere, so I can modify my setAddress()
> method to execute the SQL to update the persistent store
> directly, no muss,
> no fuss. Note that this method updates the state of the object in memory
> and in the database, so it can work with isModified() to avoid
> the execution
> of ejbStore() at commit time if nothing else changed.
>
> In fact I'd probably include the call to remove the old address there as
> well if that makes sense.
>
> Cheers
> Jay
>
> -----Original Message-----
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 9:38 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead
> to DB corruption
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Georg
> > Rehfeld
> > Sent: Monday, June 18, 2001 9:50 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead
> > to DB corruption
> >
> >
> > Hi Gentlemen,
> >
> > Jay Walters wrote:
> > > Seems like an application requiring a CMP Persistence Manager and EJB
> > > container to execute SQL in a specific order might be asking a
> > bit much to
> > > me...
> >
> > and Bill Burke replied:
> > > You'd have the same type of problems with BMP, wouldn't you?
> >
> > Sorry G's, I still can't see the point here. With BMP simply
> > ejbCreate/Store/Remove is called at the appropriate places,
> > especially ejbStore is called after every business method, isn't
> > it? If not, would someone PLEASE point me to the code that does
> > actually deferring the SQL, I just again spent 2 hours in
> > org.jboss.ejb.** hunting for it.
> >
>
> I'm pretty sure you're wrong here. BMP in jboss does NOT guarantee SQL
> ordering. BMP uses the same interceptors as CMP(look in
> standardjboss.xml)
> and there is no code in these Entity interceptors that
> differentiate between
> BMP and CMP. Somebody please correct me if I'm wrong because I'd really
> like to nail this down.
>
> > If I'm right, the BMP guy has all control over execution of SQL
> > by simply doing the OO operations in some order (having referential
> > integrity in the back of his head). Besides, is such a thing as
> > RI useless/hindering in the OO world? I don't think so, even the
> > pure OO guru respects integrity by i.e. not changing essential
> > things before he knows for sure, that relatet changes can be done.
> > (Else he would be no guru and should learn a session from the
> > relational boys).
> >
>
> Not true, see above.
>
> > And, last but not least, in the EJB context, heavily tied to
> > relational store tier (by practical implementations and at least
> > 'between the lines' of the EJB specs), it would be a shame to
> > leave people without referential integrity, by not allowing them
> > to have it on the store (Database) and not providing it in the
> > next higher level by declaration (the entiy bean level).
> >
> > Again, when the BMP guys have full control, why should EJB Server/
> > Container developers want to leave the CMP guys in the wet?
> >
> > Note, that I'm not against the push() thing just published on
> > top the EJB 2 requirement to 'store before find', but I consider
> > it 'Janus' headed: one side parfumed like a feature, the other one
> > stinking like a workaround.
> >
>
> I disagree this is klugy. I think the spec is trying to help with
> "referential integrity" while still giving the Container some room to
> optimize DB access.
>
> > Back to my past suggestion of respecting the ORDER of OO calls:
> >
> > A simple, but imperformant, solution would be to execute
> > storeEntity() after each business method and in create/remove.
> >
> > I believe now, that the real flaw is caused by the fact, that
> > the EJB specs consider every field/attribute of a bean
> > to be equal in semantics to each other, with the exception of
> > the Primary Key field(s). But they didn't learn their
> > lession really from the relational poor mens! They COMPLETELY
> > ignore the very different semantics of FOREIGN KEYS (place
> > holders for Associations of all sorts).
> >
> > This discussion threads problem never comes up, when changing
> > simple attributes/fiels, that ain't related to anything, but
> > the primary key of the bean instance (1:1, normally).
> > But it shows up, when attributes, that represent associations,
> > are modified.
> >
> > JAWS/JBoss needs to know about the SEMANTICS of fields/columns
> > and then can come up with performant/'intelligent' handling:
> >
> > If deferral to commit time is suggested, then QUEUING up all
> > store requests related to one TX (including create(), remove()
> > and store() and possibly find() for DIFFERENT instances/beans)
> > will help: if ANY store request affects data with FOREIGN KEY /
> > Association semantics, the queue must be processed physically
> > to the underlying store, until empty, before executing the call
> > with association semantics (only as a first attempt, we will
> > be better in a few days!).
> >
> > Thus several changes to simple attributes of the same bean
> > instance intermixed with creation/removal of other bean
> > instances would nicely be accumulated to only one store()
> > operation (and several unrelated create/delete_stores).
> >
> > But a change of a FOREIGN KEY / Association field would trigger
> > the queue processing before doing the change to the assoc field,
> > resolving this threads sort of problem. Further requests to simple
> > attributes then again accumulate to the queue.
> >
> > Makes sense, doesn't it?
>
> Sounds great, but what do we do until somebody takes this up and
> implements
> it?
>
> Bill
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
