I am wondering how many people are using declarative RI and entity beans? I
am sure the DBAs like the RI stuff in the database, but EJB seems to like to
be the only game in town - for example leaving it up to the container to
issue the SQL in whatever order it wants.
Cheers
-----Original Message-----
From: David Esposito [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 1:30 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
That's what I want ... I don't want the data to be committed, I just need it
to be visible by other operations that occur under the same transaction
context. In my example in my email, I neglected to mention what actually
happens when you execute my block of code:
The database throws a hemorrhage because there is a non-cascading delete RI
constraint between the member_company_address table and the credit_card
table. The situation would be even more serious if the constraint WERE
cascading (ON DELETE CASCADE) ... In that case, the remove() method on my
address object would actually remove the credit_card record in the DB that
JBOSS had its hands on. ... Both of which would be avoided if the UPDATE to
the credit_card record had happened immediately when i issued my setXXX()
method on the remote object ..
I am surprised that I am the only one that has raised this particular
example. It seems like it's something that people would do every day.
I could come up with several other illustrative examples of where this is a
problem ... but I think this one is the simplest to understand ...
-Dave
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Friday, June 15, 2001 12:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Why is this a serious problem? The weblogic docs for the flag you mention
> indicate the commit is still not done until the end of the transaction and
> that you would only notice this if your db allows for uncommitted reads.
>
> From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164
> Using delay-updates-until-end-of-tx to Change ejbStore() Behavior
>
> By default, WebLogic Server updates the persistent store of all
> beans in a transaction only at the completion (commit) of the
> transaction. This generally improves performance by avoiding
> unnecessary updates and repeated calls to ejbStore().
>
> If your datastore uses an isolation level of READ_UNCOMMITTED,
> you may want to allow other database users to view the intermediate
> results of in-progress transactions. In this case, the default
> WebLogic Server behavior of updating the datastore only at
> transaction completion may be unacceptable.
>
> You can disable the default behavior by using the
> delay-updates-until-end-of-tx deployment element. When you set
> this element to
> "false," WebLogic Server calls ejbStore() after each method call,
> rather than at the conclusion of the transaction.
>
> Note: Setting delay-updates-until-end-of-tx to false does not
> cause database updates to be "committed" to the database after each
> method invoke; they are only sent to the database. Updates are
> committed or rolled back in the database only at the conclusion of
> the transaction.
>
>
>
> ----- Original Message -----
> From: "David Esposito" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 9:01 AM
> Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> > Hello all,
> >
> > I have spent the past few hours reading up on other people with similar
> > problems to mine. So I am familiar with what the EJB spec says (somewhat
> > related to the "diamond" scenario (11.7.1 of the EJB Spec))
> with respect to
> > when a Bean is required to write its data out to persistent storage.
> > However, this seems to be counterintuitive and is a serious problem for
> > operations that manipulate multiple data sources.
> >
>
>
>
> _______________________________________________
> 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
