Ejb: best way to implement an update method with BMP

[Andrea Desole]

I want to write my first update method for an EJB using BMP. My
favourite solution would be:

bean.setA();
bean.setB();
bean.update();

The problem is that an update can only be made in the ejbStore method,
which is called at the end of a method configured to be used with a
transaction, in this case bean.update(). But, even if I use a
transaction with update, I will then have a call to ejbLoad when I
start it, which basically means that my new values for A and B will be
overwritten with the old ones. I think there are mainly two possibilities:

1) call update(A,B) instead of setA, setB, update
2) setting a flag in setA and setB. ejbLoad will then check the flag: if
the flag is set the object will not be loaded

personally, I find both solutions not that great. Is it another drawback
of EJBs, or there is a better solution?
I'm seriously considering a change of technology...

 

[Sudsy]

I want to write my first update method for an EJB using BMP. My
favourite solution would be:

bean.setA();
bean.setB();
bean.update();

The problem is that an update can only be made in the ejbStore method,
which is called at the end of a method configured to be used with a
transaction, in this case bean.update(). But, even if I use a
transaction with update, I will then have a call to ejbLoad when I start
it, which basically means that my new values for A and B will be
overwritten with the old ones. I think there are mainly two possibilities:

<snip>

I suggest a careful reread of the documentation. The container will
"bracket" your method calls (setA, setB) with calls to ejbLoad and
ejbStore. You need to understand your BMP entity bean's responsibilities.
A good book (with examples) is "Enterprise JavaBeans Component
Architecture" published by Sun Microsystems Press, ISBN 0-13-035571-2.
I would expect that you could also find a good tutorial on Sun's web
site. In fact, typing "+bmp +tutorial" into the search string box at
<http://java.sun.com> provides the following:
<http://java.sun.com/developer/onlineTraining/J2EE/Intro2/jdbc_bmp/jdbc_bmp.html>
Pay particular attention to the bean lifecycle.

 

[Andrea Desole]

<snip>

I suggest a careful reread of the documentation. The container will
"bracket" your method calls (setA, setB) with calls to ejbLoad and
ejbStore. You need to understand your BMP entity bean's responsibilities.
A good book (with examples) is "Enterprise JavaBeans Component
Architecture" published by Sun Microsystems Press, ISBN 0-13-035571-2.
I would expect that you could also find a good tutorial on Sun's web
site. In fact, typing "+bmp +tutorial" into the search string box at
<http://java.sun.com> provides the following:
<http://java.sun.com/developer/onlineTraining/J2EE/Intro2/jdbc_bmp/jdbc_bmp.html>

Pay particular attention to the bean lifecycle.

I looked at it, but that should happen usually if the method has a
transaction associated. At least, that's what I understand from the J2EE
1.4 tutorial, (page 936), and from the book "Enterprise Javabeans",
pages 250-251. From this documentation, and from the specification, I
also understand that the container can call these methods whenever it is
considered necessary.
Not every method has to have a transaction. So, if I configure my
transaction properly in the ejb-jar file, there should be no need to
call ejbStore from my setters, and it will be called only in update.
Right?

 

[Sudsy]

Andrea Desole wrote:

I looked at it, but that should happen usually if the method has a
transaction associated. At least, that's what I understand from the J2EE
1.4 tutorial, (page 936), and from the book "Enterprise Javabeans",
pages 250-251. From this documentation, and from the specification, I
also understand that the container can call these methods whenever it is
considered necessary.
Not every method has to have a transaction. So, if I configure my
transaction properly in the ejb-jar file, there should be no need to
call ejbStore from my setters, and it will be called only in update.
Right?

From the book I mentioned earlier:
"All business methods, even if they only perform a data lookup, /must/
execute within a transaction in order for the EJB container to ensure
data integrity between the in-memory entity bean and the database."
(pp. 212, emphasis mine)

 

[Andrea Desole]

I see. On the other side, I might want to call my setter without
changing the database. For example, if I call setA without setB, I might
leave the database in an inconsistent state. Not to mention the
performance, of course.
There would be no point otherwise in having the possibility to configure
the transaction type for every method

 

[Sudsy]

I see. On the other side, I might want to call my setter without
changing the database. For example, if I call setA without setB, I might
leave the database in an inconsistent state. Not to mention the
performance, of course.
There would be no point otherwise in having the possibility to configure
the transaction type for every method

<snip>

Not to be condescending, but you /really/ should do some more reading on
some of the basic concepts, particularly transactions. If you specify a
transaction-type of Required then a new transaction is started only if
the client isn't ALREADY in a transaction.
The usual way of doing things is to incorporate the business login in a
stateless session bean which has methods specified with a transaction-type
of Required. The entity EJBs can then utilize the same transaction as the
SLSB. If any of the updates fail then the entire transaction is rolled-
back, satisfying ACID requirements.
You had to figure that the J2EE architects would have addressed these
kinds of issues, right?

 

[Andrea Desole]

<snip>

Not to be condescending, but you /really/ should do some more reading on
some of the basic concepts, particularly transactions. If you specify a
transaction-type of Required then a new transaction is started only if
the client isn't ALREADY in a transaction.
The usual way of doing things is to incorporate the business login in a
stateless session bean which has methods specified with a transaction-type
of Required. The entity EJBs can then utilize the same transaction as the
SLSB. If any of the updates fail then the entire transaction is rolled-
back, satisfying ACID requirements.
You had to figure that the J2EE architects would have addressed these
kinds of issues, right?

Right. Which is the reason why I find the entire thing a bit strange.
This is one of the things about EJBs I don't understand, like the
question about the n+1 accesses for n beans I posted a while ago. If the
book you mentioned is able to give some good answers i will be glad to
read it. I have two books here, plus the tutorial and the documentation,
and supposing I understand correctly how things work (which I am not
always believing), I absolutely don't understand the reason.
Also, the solution with the extra session bean is not bad, but it adds
an extra layer of complexity (the bean), which is not really needed.
Actually, as far as I know, there is a pattern that says the code should
look like:


MyBeanData data = new MyBeanData();

data.setA( a );
data.setB( b );
myBean.update( data );


which is also okay, and it's so far my favourite solution, but it
involves an extra object. For nothing. I would like to show again what
for me is the best solution:


myBean.setA( a ); // here no transaction (transaction type is supports
or even never)
myBean.setB( b ); // here no transaction either
myBean.update(); // here transaction/rollback using the members
previously set


Sorry to argue, I agree that I should read more (which is what I'm
doing), but I'm a bit surprised to see that such a simple solution can't
be implemented.

 

[Sudsy]

Andrea Desole wrote:

myBean.setA( a ); // here no transaction (transaction type is supports
or even never)
myBean.setB( b ); // here no transaction either
myBean.update(); // here transaction/rollback using the members
previously set


Sorry to argue, I agree that I should read more (which is what I'm
doing), but I'm a bit surprised to see that such a simple solution can't
be implemented.

Your pattern looks more like a DAO and would be implemented as a session
bean, not an entity bean. The DAO could utilize underlying entity beans
or contain JDBC code. In either case you're adding another layer (or more)
which encapsulates the business logic. This is just the way it's done with
J2EE.
There's nothing wrong with your desired approach. You merely misidentified
the implementation layer. You mentioned BMP entity beans which don't work
the way you'd like in this situation.
Fair enough?

 

[Andrea Desole]

Andrea Desole wrote:



Your pattern looks more like a DAO and would be implemented as a session
bean, not an entity bean. The DAO could utilize underlying entity beans
or contain JDBC code. In either case you're adding another layer (or more)
which encapsulates the business logic. This is just the way it's done with
J2EE.
There's nothing wrong with your desired approach. You merely misidentified
the implementation layer. You mentioned BMP entity beans which don't
work the way you'd like in this situation.
Fair enough?

kind of
True, I'm using BMP, and I have to say that implementing it as a session
bean might be a good idea. I'll have to look at it.
Thanks for the help anyway.