Unfortunately, I'm using PostGres ...
Is implementing a Weblogic-style solution very complicated? especially now
that there is the finder solution implemented by Bill Burke? I'd prefer not
to have hacky code all over my app just to deal with something that can be
set externally ..
-Dave
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jay
> Walters
> Sent: Friday, June 15, 2001 3:44 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Actually Oracle will do this, are you using Oracle? You can change the
> constraint checking to be deferred until commit.
>
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 3:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Hi,
>
> Well, another possibility would be ketting your db vendor to check fk
> constraints only on transaction boundaries, which would imho make the most
> sense, however in the real world, Bill Burke just added (to cvs/2.3-2.4 I
> think) some code that forces the container to store all modifications
> before executing any finder methods. You could in your example leverage
> this feature by:
>
> get ccr.
> remember address id
> change address id
> find old address from remembered address id (forces write of the
> change you
> just made)
> remove old address.
>
> I don't know if you can always rearrange your operations to avoid extra
> finder calls, but presumably you can always make an extra one to force
> writes.
>
> It is possible that I have misinterpreted his code and you have to find an
> entity bean of the same class as the one you changed, but I don't think
> this is the case.
>
> david jencks
>
>
> On 2001.06.15 12:01:09 -0400 David Esposito wrote:
> > 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.
> >
> > The flaw is that the Container writes changes out to persistent storage
> > immediately for remove() (ejbRemove()) and create() (ejbCreate())
> > operations, however, it doesn't write changes out for other
> Bean business
> > methods until the commit() section of the transaction.
> >
> > Take the following method from my Stateless SessionBean (transaction set
> > to
> > Required for the SSB and for the two CMP beans that it is manipulating)
> >
> > public Integer runTest(Integer creditCardID, Integer
> newBillingAddressID)
> > throws EJBException
> > {
> >
> > CreditCardHome cch =
> >
> (CreditCardHome)TradeIMEJBTools.getHome("blah/CreditCardHome",Cred
> itCardHome
> > .class);
> > MemberCompanyAddressHome mcah =
> >
> (MemberCompanyAddressHome)TradeIMEJBTools.getHome("blah/MemberComp
> anyAddress
> > Home",MemberCompanyAddressHome.class);
> >
> > try
> > {
> > CreditCard cc = cch.findByPrimaryKey(creditCardID);
> > CreditCardRecord ccr = cc.getRecord();
> >
> > //Get the address that this credit card is currently pointing to
> > MemberCompanyAddress mca = mcah.findByPrimaryKey(new
> > MemberCompanyAddressPK(ccr.billing_address_id));
> >
> > //Change the address to a different one
> > ccr.billing_address_id = newBillingAddressID.intValue();
> >
> > //Write the changes to the bean object
> > cc.setRecord(ccr);
> >
> > //Remove the old address
> > mca.remove();
> >
> > return null;
> >
> >
> > }
> > catch(Exception e)
> > {
> > System.out.println("Error creating record!" + e);
> > throw new EJBException("Failure creating records!");
> > }
> > }
> >
> > Here's what the average guy would think that this does to the DB:
> >
> > BEGIN;
> >
> > SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> > {creditCardID}
> >
> > oldBillingAddressID = {previousQuery}.billing_address_id
> >
> > UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> > credit_card_id = {creditCardID}
> >
> > DELETE FROM member_company_address WHERE member_company_address_id =
> > {oldBillingAddressID}
> >
> > COMMIT;
> >
> > But in fact, the order of operations are as follows:
> >
> > BEGIN;
> >
> > SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> > {creditCardID}
> >
> > oldBillingAddressID = {previousQuery}.billing_address_id
> >
> > DELETE FROM member_company_address WHERE member_company_address_id =
> > {oldBillingAddressID}
> >
> > UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> > credit_card_id = {creditCardID}
> >
> > COMMIT;
> >
> > This is a serious problem ... Weblogic has implemented a
> > "delay-updates-until-end-of-tx" parameter to add to the deployment
> > descriptor to allow a developer to override this behavior... Is
> there any
> > chance that the same can be done to JBOSS? Borland App Server supposedly
> > has
> > something similar ... If not, does anyone have any way to work around
> > this
> > problem without writing my own BMP beans and calling ejbStore() manually
> > after each business method to the bean? Ideally, it would be
> nice to also
> > have a parameter to add to the deployment descriptor to force an
> > ejbLoad()
> > before each business method ... I understand all of the performance
> > implications of doing such things, this is why it seems like it needs to
> > be
> > part of each beans deployment descriptor rather than a global
> setting for
> > all entity beans.
> >
> > I looked at the Interceptor classes in the org.jboss.ejb.plugins
> > directory
> > and feel that it is beyond my capability to actually implement a fix
> > myself.
> > However, I would be happy to test any changes that are implemented and
> > write
> > a section of documention on how to use the new feature.
> >
> > Thanks in advance
> >
> > -Dave
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
