Colin Richardson

The EJB spec page 90 says that in the ejbCreate() and ejbRemove() methods of a BMT stateless session bean, it is OK to call getUserTransaction() but not to use any UserTransaction methods. Is this correct, and if so what would be the point of doing this?
Head First EJB combines the two things together (get the transaction reference and call methods on it), and says (page 228) that these are *not* allowed in ejbCreate() and ejbRemove().
What is *really* allowed in these methods?

In afterCompletion() you cannot call setRollbackOnly() or getRollbackOnly(), because the transaction has completed. Also you cannot access another enterprise bean or a resource manager. Page 512 of Head First EJB says "You can't do any tranaction-related things because you're no longer in a transaction. You can access ONLY your special JNDI context. It's not safe to access resource managers or other beans."
I've just been reading the spec Transactions section, and thought I understood a bit more about accessing resource managers, and how the container includes access to other resources (databases and JMS resources) within an existing transaction, so it seemed to make sense that you can't access a resource manager (and maybe another bean) from afterCompletion() because it's never within a transaction.
But then I remembered that a session bean's ejbCreate(), ejbRemove(), ejbActivate() and ejbPassivate() run in an unspecified transaction context, and we know that a bean is not passivated if it is in a transaction, so we know that ejbPassivate() will not have a transaction. But while these four methods don't allow calls to setRolbackOnly() and getRollbackOnly(), they *do* allow access to resource managers and other beans, which implies that the ability to do these things is not related to being in a transaction.
Does anybody understand why the rules are different for afterCompletion() and the four ejb* methods? I'm trying to understand why, rather than just memorise a table of what's allowed. Is the ability to access another bean and a resource manager really related to being in a transaction? Is there something I've not understood?

The thing that shook me about Sun's guidelines was that it said in the order of 3500 lines of code, or about a working week! I'm not sure I've ever worked with anybody who could write 3500 lines of reliable, properly debugged, commented, well laid out code in a week (or even 3500 lines of rubbish, come to that).
Obviously it all depends on your familiarity with the technologies being used, and the complexity of the application, but I thought the industry average was supposed to be about 100-200 lines a week (although I'm sure JavaRanchers exceed this!)?

I've only just started looking at SCJD certification (I'm just finishing my preparation for SCBCD). However, I have bought Max's book and seen that it deals with NIO. But I also looked at Sun's Certification web site for SCJD, which lists the following restrictions.
The following APIs and facilities may not be used:
Enterprise JavaBeans
Servlets, JSP technology, or any other web-oriented APIs
NIO, the New IO facilities
Java DataBase Connectivity (JDBC) and SQL
Java IDL API and CORBA
Third party software libraries or tools (such as browsers)
Is this now out of date? Do you get instructions that allow NIO when you download the assignment?

Hi Keith
Do you come from a SQL background? I do, and I'm finding EJB-QL a bit tricky because of this. EJB-SQL doesn't seem to do joins explicitly, you have to use IN with a CMR field. On page 239 of the spec, it gives an example of some EJB-QL and the equivalent SQL:
SELECT OBJECT(o)
FROM Order o, IN(o.lineItems) l
WHERE l.quantity > 5
SELECT DISTINCT o.OKEY
FROM ORDERBEAN o, LINEITEM l
WHERE o.OKEY = l.FKEY AND l.QUANTITY > 5
Does this help at all? I'm new to EJB myself, so I might be barking up the wrong tree.

Kathy,
Once again, thanks for another great answer. It's much appreciated.
Colin

Can anybody offer any help on this? Page 172 and 175 of the spec says that ejbActivate() is called when the bean instance is taken from the pool and assigned a specific identity. Does this ever happen other than as a result of a client operation?
There's probably something obvious about ejbActivate() that I'm not seeing, but I wonder if the answer in HFEJB is correct? I've checked the errata on oreilly.com and there's nothing mentioned, and I also did a search on this forum to see if I could find any previous questions on the same subject, but again didn't find anything. This suggests that it must just be that I've missed something obvious...

Kathy,
Thanks for another comprehensive answer! I did read page 234, honest, but it's just so difficult to remember if or where you might have read something before. Learning EJB, I'm reminded of a Far Side cartoon where a boy in class puts his hand up and says "Please sir, my brain is full".
I certainly like the idea of adding a summary of naming requirements to a future version of the book.
Thanks again.
Colin

Does anybody have a handy list of rules for home and component business method names?
From Head First EJB:
Page 279, entity bean home business methods cannot have the prefixes "create", "find" or "remove". Can they have the prefix "ejb"?
Page 272 says that entity bean component business methods can have arbitrary names, provided they don't begin with "ejb". Can they have the prefixes "create", "find" and "remove"? I can see that "create" and "find" have no special meaning for the component interface, but what about "remove" - there are remove methods in both home and component interfaces?
Page 133 gives a list of rules for the component interface for session beans, similar to the rules for entity beans on pages 272, 279, but it does not specify restrictions on business method names. What are the rules?
Thanks for any help!

Hi,
Head First EJB Chapter 6, question 15 (pages 366/371) asks which methods are always invoked in direct response to a client operation, and the answer says that ejbCreate() and ejbRemove() are, and ejbLoad(), ejbACtivate(), ejbPassivate() and setEntityContext() are not.
At the moment I don't understand when ejbActivate() is called other than as a direct result of a client request. It's called when the bean moves out of the pool to the method ready state - doesn't this mean that it is as the result of a client request? Does the bean move to the method ready state for other reasons?
The note with the answer on page 371 says that Load, Passivate and setEntityContext can be called by the Container when it wants to, but it doesn't mention anything about ejbActivate().
[ February 05, 2004: Message edited by: Colin Richardson ]

That list of suggested titles looks great. I was really looking forward to Head First UML & Patterns mentioned in Head First EJB, but does Bert's reply mean that plans for this have changed, or perhaps that it is more concentrated on patterns than UML?

Thanks for the replies guys. I understand now!

I have a couple of questions about stateful session bean removal I hope somebody could help me with.
Head First EJB shows four scenarios for what happens to a stateful session bean when the it dies, on pages 209-212:
1. Client calls remove() on an active (non-passivated) bean.
2. Bean times out while active.
3. Bean times out while passivated.
4. Bean throws a system exception.
First of all, does number 2 imply that it may be possible to configure a container to immediately kill a stateful session bean rather than passivate it if the client is inactive for a certain time?
Secondly, what happens if the client calls remove() while the bean is passivated()? Does ejbActivate() get called (page 204 of HFEJB says there is only one reason why ejbActivate() is called: the client called a business method; therefore I would guess that ejbActivate() cannot be called, and it doesn't seem to make sense to do so because the bean is about to die). And does ejbRemove() get called? My guess would be no, but the list of reasons why an ejbRemove() could get missed on page 215 does not include the client calling remove() while the bean is passivated. The state diagram doesn't seem to help with this question, as it shows the only ways out of the passivated state are timeout (which is not happening in this scenario) or ejbActivate(). This seems to suggest that the bean would receive ejbActivate() and ejbRemove() calls.
Any help people can offer would be appreciated.