RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 8:36 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Sunday, June 17, 2001 10:23 AM
1. Change JBoss to expose a flush method.
A.setAddress(newAddress)
((ImaginaryJBossEntityProxy)A).flush(); // Causes an ejbStore()/Update.
oldAddress.remove();
This might be the best solution ... as it minimizes the 'smoke
and mirrors'
factor that solution #2 presents ... (if people need to sync with the
database, let them do it explicitly ... don't do it implictly ... )
2. Or, as I think somebody else suggested:
A.setAddress(newAddress)
AHome.findByPrimaryKey(new APK(A.getId())); // causes a ejbStore/Update.
oldAddress.remove();
This should be a fine solution too ... I tried this just to make sure that
it didn't already work ... sadly, it doesn't cause any data to get written
out ... Ideally, it should do a read from the DB too ... just to make sure
that no data has been modified by other processes (yes, i use commit B)
since the start of the transaction ...
Doesn't work??!! Are you sure you have the latest JBoss from source? I put
this ejbStore on ejbFind in last week . Anyways, don't forget, ejbStore
will ONLY be called on entities of the same type of the finder and that are
within the same transaction.
3. Even better, have all your entity beans implement flush(),
just in case
the ejb spec or jboss comes up with a better solution you can
easily change
it.
// CMP
class YourBean implements EntityBean
public void flush() throws RemoteException
{
home.findByPrimaryKey(new MyPK(this.getId());
}
// BMP: Is this a good solution?
class YourBean implements EntityBean
public void flush() throws RemoteException
{
this.ejbStore(); // Will this work?
}
I think that for BMP, that will actually work ... since you're calling a
method with implementation from within the same object, it should
work just
fine.
Ok, so now the million dollar question ... :) ... is there any chance that
this can get stuck into 2.3/2.4? or is this a big deal that can't be
implemented in time? ... We are coming up against a launch date for our
project and this is really important ...
Shouldn't be that hard to do, just a question whether or not its something
Mr. Fleury wants within JBoss. Personnally, I think something like flush
should be added. Or maybe a better name ejbFlush or jbossFlush. I may be
able to implement it if I can find the time this week and we can patch it,
BUT...We're coming up against a launch date as well!!!
Should I add this to the bug database (even though it's not a bug, per
say) ?...
Personally I think it is a bug. It can cause some nasty problems,
especially with your CASCADE DELETE scenario! Imagine hitting that in
production??!!
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Doesn't work??!! Are you sure you have the latest JBoss from source? I put this ejbStore on ejbFind in last week . Anyways, don't forget, ejbStore will ONLY be called on entities of the same type of the finder and that are within the same transaction. Sorry 'bout that ... I hadn't downloaded the latest source ... I just did that, compiled it, and now i'm getting this for ALL of my beans ... [Member] [com.blah.ejb.member.MemberPK@d0] getRecord() [Member] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is: java.lang.NoSuchMethodError [Member] java.lang.NoSuchMethodError [Member]at org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCache.java:95 ) [Member]at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:1 66) [Member]at org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:60) [Member]at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterce ptor.java:148) [Member]at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133) [Member]at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:298) [Member]at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99) [Member]at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12 7) [Member]at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195) [Member]at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349) [Member]at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI nvoker.java:390) [Member]at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI nvoker.java:467) [Member]at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericPr oxy.java:335) [Member]at org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityProxy.java:13 3) [Member]at $Proxy75.getRecord(Unknown Source) [Member]at com.blah.servlets.UserHomeServlet.serviceRequest(UserHomeServlet.java:139) What's going on here? Am I missing some libs (JARs) somewhere? Shouldn't be that hard to do, just a question whether or not its something Mr. Fleury wants within JBoss. Personnally, I think something like flush should be added. Or maybe a better name ejbFlush or jbossFlush. I may be able to implement it if I can find the time this week and we can patch it, BUT...We're coming up against a launch date as well!!! Mr. Fleury, pretty please with sugar on top, can we have a flush feature ... pleez ... ;) Should I add this to the bug database (even though it's not a bug, per say) ?... Personally I think it is a bug. It can cause some nasty problems, especially with your CASCADE DELETE scenario! Imagine hitting that in production??!! Ok, I just added it .. -Dave ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
My fault ... I forgot to copy the client lib directory over from the build
directory ...
Ok, so that seems to be a workaround ... Here's what I did:
Changed my setRecord in my EntityBean to do something like this:
public void setRecord(CreditCardRecord rec)
{
this.member_company_id = rec.member_company_id;
this.cardholder_name= rec.cardholder_name;
this.billing_address_id = rec.billing_address_id;
//Force the changes out to the DB immediately
try{flush();}
catch(Exception e){throw new EJBException(Unable to write bean's contents
to persistent storage! + e);}
}
Then I implemented a flush() and getID() method in my EntityBean:
public void flush() throws RemoteException, FinderException
{
((CreditCardHome)context.getEJBHome()).findByPrimaryKey(getID());
}
public Integer getID(){return this.credit_card_id;}
It seems to have worked ... I ran several tests and it looks like the
Container triggers the ejbStore() when it encounters the findByXXX call ...
Is this a good long-term solution? It seems a little kludgy ...
If this is the final solution, would you like for me to document it?
-Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Doesn't work??!! Are you sure you have the latest JBoss from
source? I put
this ejbStore on ejbFind in last week . Anyways, don't
forget, ejbStore
will ONLY be called on entities of the same type of the finder
and that are
within the same transaction.
Sorry 'bout that ... I hadn't downloaded the latest source ... I just did
that, compiled it, and now i'm getting this for ALL of my beans ...
[Member] [com.blah.ejb.member.MemberPK@d0] getRecord()
[Member] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is:
java.lang.NoSuchMethodError
[Member] java.lang.NoSuchMethodError
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCac
he.java:95
)
[Member]at
org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCa
che.java:1
66)
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:60)
[Member]at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta
nceInterce
ptor.java:148)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT
.java:133)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
ceptorCMT.
java:298)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[Member]at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept
or.java:12
7)
[Member]at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[Member]at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349)
[Member]at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
ContainerI
nvoker.java:390)
[Member]at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
ContainerI
nvoker.java:467)
[Member]at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer
(GenericPr
oxy.java:335)
[Member]at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityPro
xy.java:13
3)
[Member]at $Proxy75.getRecord(Unknown Source)
[Member]at
com.blah.servlets.UserHomeServlet.serviceRequest(UserHomeServlet.java:139)
What's going on here? Am I missing some libs (JARs) somewhere?
Shouldn't be that hard to do, just a question whether or not
its something
Mr. Fleury wants within JBoss. Personnally, I think something
like flush
should be added. Or maybe a better name ejbFlush or
jbossFlush. I may be
able to implement it if I can find the time this week and we
can patch it,
BUT...We're coming up against a launch date as well!!!
Mr. Fleury, pretty please with sugar on top, can we have a flush
feature ...
pleez ... ;)
Should I add this to the bug database (even though it's not
a bug, per
say) ?...
Personally I think it is a bug. It can cause some nasty problems,
especially with your CASCADE DELETE scenario! Imagine hitting that in
production??!!
Ok, I just added it ..
-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
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
You need to make sure you got the latest from CVS for every file. Also do a build clean then build dist. It seems like you have some old class files someplace. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Esposito Sent: Monday, June 18, 2001 12:40 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem Doesn't work??!! Are you sure you have the latest JBoss from source? I put this ejbStore on ejbFind in last week . Anyways, don't forget, ejbStore will ONLY be called on entities of the same type of the finder and that are within the same transaction. Sorry 'bout that ... I hadn't downloaded the latest source ... I just did that, compiled it, and now i'm getting this for ALL of my beans ... [Member] [com.blah.ejb.member.MemberPK@d0] getRecord() [Member] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is: java.lang.NoSuchMethodError [Member] java.lang.NoSuchMethodError [Member]at org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCac he.java:95 ) [Member]at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCa che.java:1 66) [Member]at org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:60) [Member]at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta nceInterce ptor.java:148) [Member]at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT .java:133) [Member]at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter ceptorCMT. java:298) [Member]at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99) [Member]at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept or.java:12 7) [Member]at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195) [Member]at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349) [Member]at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP ContainerI nvoker.java:390) [Member]at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP ContainerI nvoker.java:467) [Member]at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer (GenericPr oxy.java:335) [Member]at org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityPro xy.java:13 3) [Member]at $Proxy75.getRecord(Unknown Source) [Member]at com.blah.servlets.UserHomeServlet.serviceRequest(UserHomeServlet.java:139) What's going on here? Am I missing some libs (JARs) somewhere? Shouldn't be that hard to do, just a question whether or not its something Mr. Fleury wants within JBoss. Personnally, I think something like flush should be added. Or maybe a better name ejbFlush or jbossFlush. I may be able to implement it if I can find the time this week and we can patch it, BUT...We're coming up against a launch date as well!!! Mr. Fleury, pretty please with sugar on top, can we have a flush feature ... pleez ... ;) Should I add this to the bug database (even though it's not a bug, per say) ?... Personally I think it is a bug. It can cause some nasty problems, especially with your CASCADE DELETE scenario! Imagine hitting that in production??!! Ok, I just added it .. -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
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Is this kludgy? Yes, but you don't have to worry about it ever not working
unless the EJB spec changes. The EJB Spec requires that all entities of the
same type of a finder get synchronized with the database before the finder
executes. (See section 9.6.4).
Add the finder workaround to the comments section of the bug you
submitted.
IMHO, this is not the best long term solution. I think flush should be
added as a jboss method, but that's just my opinion. I'm pretty new to
JBoss myself and I'm waiting for some others to chime in their advice. I'll
repost this question later if I get no responses.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 1:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
My fault ... I forgot to copy the client lib directory over from the build
directory ...
Ok, so that seems to be a workaround ... Here's what I did:
Changed my setRecord in my EntityBean to do something like this:
public void setRecord(CreditCardRecord rec)
{
this.member_company_id = rec.member_company_id;
this.cardholder_name= rec.cardholder_name;
this.billing_address_id = rec.billing_address_id;
//Force the changes out to the DB immediately
try{flush();}
catch(Exception e){throw new EJBException(Unable to write
bean's contents
to persistent storage! + e);}
}
Then I implemented a flush() and getID() method in my EntityBean:
public void flush() throws RemoteException, FinderException
{
((CreditCardHome)context.getEJBHome()).findByPrimaryKey(getID());
}
public Integer getID(){return this.credit_card_id;}
It seems to have worked ... I ran several tests and it looks like the
Container triggers the ejbStore() when it encounters the
findByXXX call ...
Is this a good long-term solution? It seems a little kludgy ...
If this is the final solution, would you like for me to document it?
-Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Doesn't work??!! Are you sure you have the latest JBoss from
source? I put
this ejbStore on ejbFind in last week . Anyways, don't
forget, ejbStore
will ONLY be called on entities of the same type of the finder
and that are
within the same transaction.
Sorry 'bout that ... I hadn't downloaded the latest source ...
I just did
that, compiled it, and now i'm getting this for ALL of my beans ...
[Member] [com.blah.ejb.member.MemberPK@d0] getRecord()
[Member] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is:
java.lang.NoSuchMethodError
[Member] java.lang.NoSuchMethodError
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCac
he.java:95
)
[Member]at
org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCa
che.java:1
66)
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:60)
[Member]at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta
nceInterce
ptor.java:148)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT
.java:133)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
ceptorCMT.
java:298)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[Member]at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept
or.java:12
7)
[Member]at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[Member]at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349)
[Member]at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
ContainerI
nvoker.java:390)
[Member]at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
ContainerI
nvoker.java:467)
[Member]at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer
(GenericPr
oxy.java:335)
[Member]at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityPro
xy.java:13
3)
[Member]at $Proxy75.getRecord(Unknown Source)
[Member]at
com.blah.servlets.UserHomeServlet.serviceRequest(UserHomeServlet.java:139)
What's going on here? Am I missing some libs (JARs) somewhere?
Shouldn't be that hard to do, just a question whether or not
its something
Mr. Fleury wants within JBoss. Personnally, I think something
like flush
should be added. Or maybe a better name ejbFlush or
jbossFlush. I may be
able to implement it if I can find the time this week and we
can patch it,
BUT...We're
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
On Mon, 18 Jun 2001, Bill Burke wrote:
Is this kludgy? Yes, but you don't have to worry about it ever not working
unless the EJB spec changes. The EJB Spec requires that all entities of the
same type of a finder get synchronized with the database before the finder
executes. (See section 9.6.4).
Please stop quoting section 9.6.4! If you look at the EJB 2.0
PFD2, which I think is the latest, section 9.6.4 deals with adding
arbitrary methods to home interfaces, and has nothing to do with finders.
I'm even a little worried that some of the requirements you're qouting may
be gone in the latest version, though I know the store beans in same
transaction as finder one is still there.
Aaron
Add the finder workaround to the comments section of the bug you
submitted.
IMHO, this is not the best long term solution. I think flush should be
added as a jboss method, but that's just my opinion. I'm pretty new to
JBoss myself and I'm waiting for some others to chime in their advice. I'll
repost this question later if I get no responses.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 1:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
My fault ... I forgot to copy the client lib directory over from the build
directory ...
Ok, so that seems to be a workaround ... Here's what I did:
Changed my setRecord in my EntityBean to do something like this:
public void setRecord(CreditCardRecord rec)
{
this.member_company_id = rec.member_company_id;
this.cardholder_name= rec.cardholder_name;
this.billing_address_id = rec.billing_address_id;
//Force the changes out to the DB immediately
try{flush();}
catch(Exception e){throw new EJBException(Unable to write
bean's contents
to persistent storage! + e);}
}
Then I implemented a flush() and getID() method in my EntityBean:
public void flush() throws RemoteException, FinderException
{
((CreditCardHome)context.getEJBHome()).findByPrimaryKey(getID());
}
public Integer getID(){return this.credit_card_id;}
It seems to have worked ... I ran several tests and it looks like the
Container triggers the ejbStore() when it encounters the
findByXXX call ...
Is this a good long-term solution? It seems a little kludgy ...
If this is the final solution, would you like for me to document it?
-Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Doesn't work??!! Are you sure you have the latest JBoss from
source? I put
this ejbStore on ejbFind in last week . Anyways, don't
forget, ejbStore
will ONLY be called on entities of the same type of the finder
and that are
within the same transaction.
Sorry 'bout that ... I hadn't downloaded the latest source ...
I just did
that, compiled it, and now i'm getting this for ALL of my beans ...
[Member] [com.blah.ejb.member.MemberPK@d0] getRecord()
[Member] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is:
java.lang.NoSuchMethodError
[Member] java.lang.NoSuchMethodError
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCac
he.java:95
)
[Member]at
org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCa
che.java:1
66)
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:60)
[Member]at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta
nceInterce
ptor.java:148)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT
.java:133)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
ceptorCMT.
java:298)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[Member]at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept
or.java:12
7)
[Member]at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[Member]at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349)
[Member]at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
ContainerI
nvoker.java:390)
[Member]at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
ContainerI
nvoker.java:467)
[Member]at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer
(GenericPr
oxy.java:335)
[Member]at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityPro
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Uhm, i tried to add a comment to the bug report but it doesn't show up for
some reason ... I don't know if i don't have permission, or what ... but
here's what I wanted to paste in there:
-
Known workaround:
Add the following methods to your EntityBean object:
public void flush() throws RemoteException, FinderException{
((MyBeanHome)context.getEJBHome()).findByPrimaryKey(getID());
}
public Integer getID(){return this.primary_key_field;}
OR
public Object getID() throws IllegalStateException
{return context.getPrimaryKey();}
Then, either add a flush() method to your Remote interface, or place a call
to flush() at the end of each of your setters for which you want an
immediate flush. For example:
//Force the changes out to the DB immediately
try{flush();}
catch(Exception e){throw new EJBException(Unable to write bean's contents
to persistent storage! + e);}
-
Thanks to all who contributed to this discussion ...
-Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Monday, June 18, 2001 1:53 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Is this kludgy? Yes, but you don't have to worry about it ever
not working
unless the EJB spec changes. The EJB Spec requires that all
entities of the
same type of a finder get synchronized with the database before the finder
executes. (See section 9.6.4).
Add the finder workaround to the comments section of the bug you
submitted.
IMHO, this is not the best long term solution. I think flush should be
added as a jboss method, but that's just my opinion. I'm pretty new to
JBoss myself and I'm waiting for some others to chime in their
advice. I'll
repost this question later if I get no responses.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday, June 18, 2001 1:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
My fault ... I forgot to copy the client lib directory over
from the build
directory ...
Ok, so that seems to be a workaround ... Here's what I did:
Changed my setRecord in my EntityBean to do something like this:
public void setRecord(CreditCardRecord rec)
{
this.member_company_id = rec.member_company_id;
this.cardholder_name= rec.cardholder_name;
this.billing_address_id = rec.billing_address_id;
//Force the changes out to the DB immediately
try{flush();}
catch(Exception e){throw new EJBException(Unable to write
bean's contents
to persistent storage! + e);}
}
Then I implemented a flush() and getID() method in my EntityBean:
public void flush() throws RemoteException, FinderException
{
((CreditCardHome)context.getEJBHome()).findByPrimaryKey(getID());
}
public Integer getID(){return this.credit_card_id;}
It seems to have worked ... I ran several tests and it looks like the
Container triggers the ejbStore() when it encounters the
findByXXX call ...
Is this a good long-term solution? It seems a little kludgy ...
If this is the final solution, would you like for me to document it?
-Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of David
Esposito
Sent: Monday, June 18, 2001 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a
serious problem
Doesn't work??!! Are you sure you have the latest JBoss from
source? I put
this ejbStore on ejbFind in last week . Anyways, don't
forget, ejbStore
will ONLY be called on entities of the same type of the finder
and that are
within the same transaction.
Sorry 'bout that ... I hadn't downloaded the latest source ...
I just did
that, compiled it, and now i'm getting this for ALL of my beans ...
[Member] [com.blah.ejb.member.MemberPK@d0] getRecord()
[Member] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is:
java.lang.NoSuchMethodError
[Member] java.lang.NoSuchMethodError
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCac
he.java:95
)
[Member]at
org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCa
che.java:1
66)
[Member]at
org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:60)
[Member]at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta
nceInterce
ptor.java:148)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT
.java:133)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
ceptorCMT.
java:298)
[Member]at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder Sent: Monday, June 18, 2001 2:04 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem On Mon, 18 Jun 2001, Bill Burke wrote: Is this kludgy? Yes, but you don't have to worry about it ever not working unless the EJB spec changes. The EJB Spec requires that all entities of the same type of a finder get synchronized with the database before the finder executes. (See section 9.6.4). Please stop quoting section 9.6.4! If you look at the EJB 2.0 PFD2, which I think is the latest, section 9.6.4 deals with adding arbitrary methods to home interfaces, and has nothing to do with finders. I'm even a little worried that some of the requirements you're qouting may be gone in the latest version, though I know the store beans in same transaction as finder one is still there. Sorry, I've got an old spec(*embarassed, downloaded last March. :-(). It's still in section 10.5.3 though. Instance life cycle contract... Container's view. Didn't know EJB 2.0 was such a moving target. Bill [snip] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Saturday, June 16, 2001 8:06 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
Hi,
A couple of comments
1. I think the worst problems can be eliminated by simply extending Bill's
store before load to include store before remove and possibly store
before create although I don't have an example of why the last one would
help.
BTW, its store before find not store before load. The finder solution I
put in CANNOT be extended to fix the problem David Esposito is having.
store before find only effect entities of the same type. In David
Esposito's example:
---
A.setAddress(newAddress)
oldAddress.remove()
delete happens before update thus constraint on bean A is violated, or if ON
DELETE CASCADE, bean A gets deleted.
---
There are 2 types of beans here Bean A and Address. My code does not keep
track of all Entities within the transaction.
Wouldn't a better solutions to have some kind of flush capability for each
Entity? In this way, you can fine tune your app in anyway you want.
(Personally, in our app, we're more worried about too many DB updates rather
than this scenario. We NEVER call bean.remove() but rather mark the row as
deleted.)
1. Change JBoss to expose a flush method.
A.setAddress(newAddress)
((ImaginaryJBossEntityProxy)A).flush(); // Causes an ejbStore()/Update.
oldAddress.remove();
2. Or, as I think somebody else suggested:
A.setAddress(newAddress)
AHome.findByPrimaryKey(new APK(A.getId())); // causes a ejbStore/Update.
oldAddress.remove();
3. Even better, have all your entity beans implement flush(), just in case
the ejb spec or jboss comes up with a better solution you can easily change
it.
// CMP
class YourBean implements EntityBean
public void flush() throws RemoteException
{
home.findByPrimaryKey(new MyPK(this.getId());
}
// BMP: Is this a good solution?
class YourBean implements EntityBean
public void flush() throws RemoteException
{
this.ejbStore(); // Will this work?
}
BTW, GOOD stuff Mr. Esposito!
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
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
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
The behavior you'd get by setting that flag to false in weblogic would also allow him to not break referential integrity in the case of his transaction. Scott M Stark wrote: 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 Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! I thought of suggesting that he put the 'setRecord' method into a RequiresNew transaction, but that would break his transactional semantics (and might deadlock him). I suppose he could just break the remove into a separate transaction, but logically, the code he has is exactly what makes sense as a single transaction. Jay Walters wrote: He wants the update SQL to execute before the remove SQL? The commit isn't the issue, it's the order of operations. What does the spec say about when remove() needs to execute the SQL? My question would be, if the bean has been removed should the persistence manager still be trying to update it? I can understand that one might want to somehow consider side effects, such as a database trigger so maybe one can't optimize out the update. Cheers -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] 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. snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Sorry. Ok so I'll read a little slower next time. Now that you've explained it, how would it work to use database RI underneath an EJB application. If the bean is in memory but disappears from the database that isn't all that good. If he's using commit option C, then next client to reference the bean will get what? Object does not exist when they try to execute a method on the bean? Cheers -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 1:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
Here's an example to further illustrate why delayed ejbStore() is problematic. What about a situation where you keep a 'bucket' in a table to improve the performance of your application. For example, you keep a current_account_balance in your User table rather than doing a SUM(transaction_amount) on your Transactions table each time you need an account balance. In a Session Bean, I should be allowed to do something like the following (very roughly pseudocoded): TransactionBean t = transHome.findByPK(xxx); t.setTransactionAmount(765.99); DataSource ds = (DataSource)lookup(MyDS); Connection con = ds.getConnection(); Statement stat = con.createStatement(); ResultSet rs = stat.executeQuery(SELECT SUM(transaction_amount) AS total FROM Transactions WHERE user_id = 444); UserBean u = userHome.findByPK(444); u.setCurrentAccountBalance(rs.next().getFloat(total)); Something like that ... In the above case (i've tried it in several areas in my app), the SELECT() statement is still reading the old data because the Container hasn't written the changes out ... Of course, I MUST ensure that this happens in a transaction so that in case there is a problem, I don't end up with unsynchronized data .. (I use this example to point out that it's not just that ejbRemove happens immediately ... making ejbRemove delay as well would not fix the situation i just described) -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch (Dan Christopherson) Sent: Friday, June 15, 2001 1:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! I thought of suggesting that he put the 'setRecord' method into a RequiresNew transaction, but that would break his transactional semantics (and might deadlock him). I suppose he could just break the remove into a separate transaction, but logically, the code he has is exactly what makes sense as a single transaction. Jay Walters wrote: He wants the update SQL to execute before the remove SQL? The commit isn't the issue, it's the order of operations. What does the spec say about when remove() needs to execute the SQL? My question would be, if the bean has been removed should the persistence manager still be trying to update it? I can understand that one might want to somehow consider side effects, such as a database trigger so maybe one can't optimize out the update. Cheers -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] 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. snip ___ 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
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
David Esposito wrote: 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. Actually it's far more common for people to complain about behavior closer to what you want - Why is ejbStore being called so often? when they access an entity directly from their client code. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
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
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,CreditCardHome
.class);
MemberCompanyAddressHome mcah =
(MemberCompanyAddressHome)TradeIMEJBTools.getHome(blah/MemberCompanyAddress
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]
RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
I agree completely with you ... I knew when I wrote the original message that there would be some strong opinions from both sides of the aisle... I'm obviously shaded to the RDB side of the aisle mostly because I realize that there are major performance benefits to letting the database do the work ... For large applications where a particular entity may have millions of records, it's impractical to assert that keeping all of the business logic in the Java space is the best choice. There are a few ways to handle this and each has its pros and cons. The unfortunate part of this not being addressed in the bean spec is that each Container provider will implement their own solution to this problem ... I'm not a super big fan of Weblogic's solution, but it's better than nothing ... A) Implement a hack to the Remote interface so that if there is a load() or store() method in the remote interface, this will trigger the appropriate ejbLoad (loadEntity) or ejbStore (storeEntity) actions ... (similar to the way that remove() triggers the ejbRemove (removeEntity) method) Pros: This will give developers the highest level of control over how the bean is synchronized with persistent storage ... We will also maintain a level of caching at the bean layer which would be better than the weblogic solution .. (i.e. When there isn't a need to synchronize with the DB, we can use the current Container behavior of keeping the data cached until commit) Cons: It means that our application (client) code has to be JBOSS specific ... B) Implement a change to the deployment descriptor similar to Weblogic's Pros: This keeps the details out of the application (client) and in the hands of the Container. If this is addressed in a future bean spec or there is some consensus on how to deal with this in the future, less code changes and regression testing will be neccessary Cons: This will lead to a performance drop for the 90% of the cases where I use my particular bean and this problem DOESN'T manifest itself ... Our general policy is to only have one getXX() method and one setXX() method for a bean that reads and writes all of the fields in one shot (to minimize RMI overhead) but does increase the overall network load ... so in our case, this wouldn't really be a major performance issue because most of the beans only have one setter ... C) Do nothing Pros: Zero development time ... Keeps the OO purists happy Cons: It will make us rethink our use of JBOSS and EJBs, and either move to Weblogic, or abandon EJBs entirely ... Personally, I would be satisfied with solution A or B ... ;) ... Solution B is somewhat more desireable for the purists in the room because it leaves the details of persistence out of the application developer's hands (well, not completely, they would still have to add the flag to th deployment descriptor, but they wouldn't have to worry about should i force a store() after these set operations?) ... Solution A is somewhat problematic because there are some backwards compatibility issues ... Anyway ... I appreciate everyone's input to this issue as it is a pretty significant roadblock for our project... We have been very impressed with the quality of JBOSS and we have made very positive comments to our fellow Weblogicians about the JBOSS ... -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch (Dan Christopherson) Sent: Friday, June 15, 2001 2:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem I think in this example, though, you're mixing paradigms too much. If you want to write SQL in session beans, go ahead. If you want to use entity beans as an object layer over the database, do that. You will have to be very carefull in mixing them this way. purist-hatEJBs are intended to be an Java/OO technology - I'd expect to do the summation in the Java space, not the SQL one./purist-hat Will that perform well enough? It depends on the sizes of your datasets and how you define 'well enough'. I think this is another case of the various trade-offs in the EJB spec - Its a distributed object component technology, and dismays the RDB folks sometimes, but a lot of it seems aimed so squarly at relational storage on the backend that it bothers the OO purists at other times. Imagine if the default behavior were for the ejb container to perform store after every method call - people would flog the database to death calling individual getters and setters! Adding an option to perform ejbStore inline would need to have a fairly fine degree of granularity - per method, I think. David Esposito wrote: Here's an example to further illustrate why delayed ejbStore() is problematic. What about a situation where you keep a 'bucket' in a table to improve the performance of your application. For example, you keep a current_account_balance in your User table rather than doing a SUM
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,CreditCardHome
.class);
MemberCompanyAddressHome mcah =
(MemberCompanyAddressHome)TradeIMEJBTools.getHome(blah/MemberCompanyAddress
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
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
Hi all, trying to sort that out. David Esposito showed us a perfectly OK sequence of modifications to some Entity beans within one TX. He reported problems with JBoss accessing the DB while persisting, because of changed order of modifications, creates/deletes seem to be done before updates, regardless of the OO sequence of calls. This comes surprising to me, anybody around to tell, if and why this is the case? Is it only with CMP somehow, I can't see this with BMP? Everything would be OK, if JBoss did sync in the very same order to the DB as the OO code requested it. Regardless of doing the ejbStore() at the end of TX or after calling a business method: just do it in the same order. Even intermixed stores would be no problem, when done IN THE SAME ORDER (this respecting the recent change to finders doing a store before finding, as requested by EJB spec 2.0). Please remember: a TX on a DB actually SEES the changes it has done in it, although no other TX can see that until commit. Now to the RI (referential integrity) thing: A DB RI setting of ON DELETE CASCADE must be considered as beeing another application modifying the DB concurrently to JBoss, so the commit option HAS to be set to at least B, and the code in the beans then MUST be prepared to accept concurrent changes by some app outside JBoss and handle that gracefully. I.e. in Davids case he must be prepared to expect cc.setRecord() to fail IF HE HAD called mca.remove() HIMSELF BEFORE or IF HE HADN'T FETCHED mca BEFORE modification to cc ... but his code still is OK. A DB RI setting of checking validity of Foreign Keys should not be problematic even with commit option A (note off topic: depending on your mapping of inheritance to your DB this COULD be a problem). Besides, not changing the order of access to the DB leaves control of LOCKING to the bean implementor, thus DEADLOCK avoidance is to him ... but he hasn't the same possibilities, as the typical relational DB developer has: the RDB developer always can ROLLBACK when he discovers, that some required lock can't be aquired (SELECT ... FOR UPDATE NOWAIT for Oracle, similar for other RDMS's). The EJB developer is lost here, the spec simply drops him 'serialized' possibly waiting for a bean held by his competitor which itself is blocked cyclic. The only way to handle deadlock is 'ordered access', which in practice seems to be impossible, especially respecting the above requested access to the DB in the same order, as the OO code needs/expects it. There is a hint in the EJB specs 1.1, that the container might reorder access to the DB to actually try ORDERED access to the DB (i.e. in increasing PK order) to avoid deadlock. But I just now can't come up with a pattern, that is safe and avoids deadlock, any taker? Conclusion: today let JBoss respect the OO order of access to beans and do it the same way to the DB. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
