Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!

Christian D. Th. Sellberg

Greenhorn
+ Follow
since Apr 02, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian D. Th. Sellberg

I believe that when the client calls remove then it triggers the container to call ejbActivate and then ejbRemove.
If you look at the life cycle state diagram of a statefull session bean on page 77 in the spec then there is no transition from �passive� to �does not exist� which is triggered by remove(). I also make sense if you imagine passivation as if the bean were serialized, then there would be no active bean instance to call ejbRemove on.



Christian

Originally posted by Lionel Orellana:
According to HFEJB page 460 it is only for BMT ...



Can anyone explain why you can't use it for CMT?



I think the answer should be found in how JMS works. In JMS when you use distributed transactions (i.e. CMT) you cannot set the delivery mode, the message is acknowledged when the transaction commits successfully. That�s why you shouldn�t set acknowledge mode when using CMT.

When you use BMT the message is acknowledged when you return normally from the onMessage method, i.e. that you do not throw a RuntimeException from inside the onMessage method. The difference between Auto-acknowledge and Dups-ok-acknowledge is that with Auto-acknowledge the bean provider is guaranteed that the message is only delivered once-and-only-once with Dups-ok-acknowledge you do not have that guarantee, and the bean provider should write could that can handle that the same message is delivered more than once. Dups-ok-acknowledge is supposed to be more performance efficient than Auto-acknowledge.
[ July 13, 2004: Message edited by: Christian D. Th. Sellberg ]
Hi All,

I have a delved a little into the transaction context issue and have found the following in the spec on page 76.

quote:
---
A session bean�s newInstance, setSessionContext, ejbCreate, ejbRemove, ejbPassivate, ejbActivate, and afterCompletion methods are called with an unspecified transaction context. Refer to Subsection 17.6.5 for how the Container executes methods with an unspecified transaction context.
---

As far as I can read the spec there is no difference between stateless and stateful session beans regarding the unspecified transaction context of newInstance, setSessionContext, ejbCreate, ejbRemove, ejbPassivate, ejbActivate, and afterCompletion. Even though the client calling create on the home interface triggers the containers call to ejbCreate, the transaction context of ejbCreate of a stateful session is still unspecified. If you look in the spec on page 80 you can see that you are not allowed to call getRollbackOnly or setRollbackOnly in ejbCreate (and ejbRemove, ejbActivate and ejbPassivate) on the SessionContext of a stateful session bean because the transaction context is unspecified in these methods.

In the unspecified transaction context of a stateful session bean I think the bean provider can do things with resource managers and other enterprise beans with does not require an ongoing transaction. E.g. the bean provider can call other enterprise beans as long as the transaction attributes of the methods called is not set to Mandatory. The bean provider should not write could code which is expected to run in the same transaction context as the client initiating the call.

Kind regards
Christian
Hi Alec,

I can only find the following about PrimaryKey�s related to your question in the spec on page 203

---
10.8.2 Primary key that maps to multiple fields in the entity bean class
The primary key class must be public, and must have a public constructor with no parameters.

All fields in the primary key class must be declared as public.

The names of the fields in the primary key class must be a subset of the names of the container-managed fields.
(This allows the container to extract the primary key fields from an instance�s container-managed
fields, and vice versa.)
---

As I read it the bean provider does not have to supply setter and getters for the pk fields.
The only requirement is that the pk fields of the PrimaryKey class are public and that they match the names of container-managed persistent fields.

This also seems to be how the JBoss 4.0 developers have read the spec. JBoss does not expect getter and setters on primary keys. JBoss only verifies that the fields are public, have matching names with the container-managed persistent fields and that the hashCode and equals are implemented correctly and it will throw a run time error if the PrimaryKey does not have a default constructor with no arguments.

Kind regards
Christian
Hi Shankar

For stateless session beans a part of a explanation for question 1 and 2 is that setSessionContext (and ejbCreate) is called by the container when the stateless session beans moves from the state �does not exist� to the state �method-ready pool�, this state transition is not triggered by any client call (see page 89 in the specification). I.e. you have an unspecified transaction context and there is no client to get security information about.

For stateful session beans I think that the spec gives a part of an explanation to your second question in a note on page 76

quote:
---
The ejbCreate and ejbRemove methods are not controlled by a transaction attribute because handling
rollbacks in these methods would greatly complicate the session instance�s state diagram.
---
setSessionContext is called by the container before ejbCreate so the reasoning in the quote above must apply here as well.

With out the spec actually saying so I get the impression that this note is the explanation for your question as well. I guess the restrictions mentioned in your question apply because otherwise it would make the state diagram of a session bean to complicated. new instance, setSessionContext and ejbCreate are all called in serialization in the state transition from �does not exist� to �method ready�. E.g. in the stateful session bean state diagram on page 77 in the specification you would have to introduce some additional state like �security context ready� before the call to setSessionContext if it should be allowed to access client specific security information in setSessionContext.

Kind regards
Christian
Hi All,

I have a question about the string function LOCATE of EJB-QL.

The book Enterprise JavaBeans by Monson-Haefel says that the correct use of the LOCATE method is as exemplified by

SELECT OBJECT(c) FROM Customer c WHERE � LOCATE(c.lastName, �Monson�)>-1

This query is supposed to return all Customers having �Monson� in their last name, but in Jboss 4.0 it only works when you write

SELECT OBJECT(c) FROM Customer c WHERE � LOCATE( �Monson�, c.lastName)>0.

I.e. in Jboss the string index starts at 1 (like in JDBC), not found returns 0, and the order of the arguments to LOCATE are the opposite as in Monson-Haefels example.

The specification does not specify the use of LOCATE but refer to a book

quote:
---
These functions are a subset of the functions defined for JDBC 2.0 drivers, as described in Appendix A in JDBC API tutorial and Reference, Second Edition.�
---

I do not have the book �JDBC API tutorial and Reference, Second Edition� at the time of writing.

What is the correct use of LOCATE? Is it JBoss or Monson-Haefel who got it right?

Kind regards
Christian

[ July 10, 2004: Message edited by: Christian Dauer Th. Sellberg ]
[ July 10, 2004: Message edited by: Christian Dauer Th. Sellberg ]
Hi Alex,

I think that your last comment was the answer:

quote:
---
If ejbLoad()/ejbStore() CANNOT be invoked on a bean that does not currently service the client's method call then everything is clear . In this case a bean will always be associated with the client and run in "meaningful transaction context" (provided that a business method that caused these methods' invocation has appropriate transaction attribute) when ejbLoad()/ejbStore() is invoked by the container on the bean.
---

Because: The entity bean can be in one of three states, �Does Not Exist�, �Pooled� and �Ready�. The entity bean only enters the ready state upon a client request.

From the spec page 169
---
An instance transitions from the pooled state to the ready state when the container selects that instance to service a client call to an entity object.
---

I think that�s an answer to your question because in your quote from the spec you mention that ejbLoad and ejbStore can only be called when the entity bean is in the ready state and the specs says that then the bean is always associated with a client.

The spec guarantees that you can access client specific information in ejbLoad and ejbStore, so for me that means that ejbLoad and ejbStore is not called by the container between client initiated transactions in option A and B. The container can choose to synchronize with the entity in the database as it pleases between client-initiated transactions but if it does then these synchronizations must not be followed up by calls to ejbLoad and ejbStore.

The spec has this note (page 187) about option B (and C) that makes sense given the explanation above.

---
Note: The Bean Provider relies on the ejbLoad() method to be invoked when commit options B and C are used in order to resynchronise the bean�s transient state with its persistent state. It is the responsibility of the container to call the ejbLoad()method at the beginning of a new transaction when commit option B or C is used.
---

The spec also has the following note about ejbLoad (page 173)

---
This method executes in the transaction context determined by the transaction attribute of the business method that triggered the ejbLoad method.
---

The spec does not mention anywhere the possibility that ejbLoad or ejbStore can be called by the container unrelated to a client call. The transaction context of ejbLoad and ejbStore is only unspecified when the transaction attribute of the business method which triggered the call to ejbLoad or ejbStore was NotSupported, Never, or Supports.


Kind regards
Christian
[ July 10, 2004: Message edited by: Christian Dauer Th. Sellberg ]
Hi Carlos,

All entity bean methods which are invoked by the container in relation to a client call can participate in the clients transaction i.e. ejbCreate, ejbPostCreate, ejbRemove, ejbHome, ejbLoad, ejbStore and all business methods.

The following methods are invoked by the container unrelated to a client call: setEntityContext, unsetEntityContext, ejbActivate and ejbPassivate.

Kind regards
Christian
Hi Mark,

[I have edited my answer regarding stateful session beans]

The transaction context in ejbCreate and ejbRemove depends on the type of bean you are looking at. For entity beans, the containers call to the ejbCreate and ejbRemove methods is related to the client call and can therefore participate in the caller�s transaction and therefore access resource managers other enterprise beans etc. For stateless session beans and message driven beans the containers call to the ejbCreate and ejbRemove methods is not related to a client call and can therefore not participate in the caller�s transaction, in other words the transaction context is unspecified, i.e. you cannot write code that depends on a transaction being present.

For stateful session beans the transaction is also unspecified in ejbCreate and ejbRemove but the explanation given above does not apply here because the containers call to ejbCreate and ejbRemove is related to the client call. The spec gives the following reason (page 76)
-----
�. The ejbCreate and ejbRemove methods are not controlled by a transaction attribute because handling
rollbacks in these methods would greatly complicate the session instance�s state diagram. �.
-----
So for statefull session beans you can access resource managers and enterprise beans in ejbCreate and ejbRemove in a way that do not depend on a transaction being present.

Kind regards
Christian
[ July 09, 2004: Message edited by: Christian Sellberg ]
Hi Sandesh,

It depends on what type of bean you are looking at. For stateless session beans using BMT the spec says the following.

-----
If a stateless session bean instance starts a transaction in a business method, it must commit the transaction
before the business method returns. The Container must detect the case in which a transaction was
started, but not completed, in the business method, and handle it as follows:
- Log this as an application error to alert the system administrator.
- Roll back the started transaction.
- Discard the instance of the session bean.
- Throw the java.rmi.RemoteException to the client if the client is a remote client, or
throw the javax.ejb.EJBException if the client is a local client.
-----

The same applies for message driven beans, except for the last point because there is no client.

For stateful session beans the container can retain the transaction across multiple client calls and will therefore not rollback the transaction.

Kind regards
Christian