Originally posted by Pradeep Bhat:
Entity beans can be reentrant. IN MDB reentrant does not make sense because client cannot directly invoke the bean but the container does and container makes sure that no more than one request is made to a bean.
Originally posted by Chris Mathews:
Actually, the EJB Specification explicitly makes a point of not specifying the transactional context for the ejbCreate() lifecycle event of Session Beans (and a few other lifecycle methods). Some Application Servers may allow you to begin a transaction in ejbCreate(), others may not. Therefore, attempting to start a transaction in ejbCreate() of a Session Bean should be avoided if you are looking to create a portable solution.
For more information on this, see 17.6.5 of the EJB 2.0 Specification.
Originally posted by Akasmat de Goa:
Sorry , let me elaborate
What i meant is does the JVM perform any optimizations on the method getClass() declared as final in java.lang.Object at runtime so that the cost of calling the getClass() method a number of times is nullified ?
e.g Does the JVM already have the class name in memory (when the class loader loads the class) or something to that effect so that my calls to getClass() would be optimized -- which in turn would make it more efficient to use rather than the second way i.e Assigning getClass() to a final variable and using that variable thereby precluding calls to getClass().getName().
Originally posted by Terry McKee:
So does Home refer to a deployed location? If I have two servers that are part of the same application and an EJB is deployed on both of the servers - there would be two distinct home(s)?
Originally posted by Kalpesh Soni:
I did not want to take ANY chances, so just scheduled my exam on this saturday, 6th june
Originally posted by Andrew Perepelytsya:
B, C - these are valid Java constructs that have no restrictions for EJB.
Originally posted by karthik Guru:
In Page 347 of the spec, they have given an example wherein a Session bean holds on to a transaction w/o commiting over multiple methods.
method1() does a begin()
and then method3 does a commit finally.
Now the spec also says that a business method in a stateless session bean must commit a transaction before it returns. Is'nt method1() supposed to do a commit before returning?
Does this mean that the bean they are referring to in the code is "Stateful" and NOT "Stateless"?
Or am I missing something?
Originally posted by Kathy Sierra:
Match the operation in list ONE with the method in list TWO in which that operation can be performed, for a stateful session bean:
LIST ONE: Operations (things you want to do)
1) invoke the SessionContext.setRollbackOnly()
2) invoke the UserTransaction.setRollbackOnly()
3) access this bean's own EJBObject interface
4) access this bean's own home interface
5) access a reference to another EJB
LIST TWO: Bean methods in which the operations from list one can be performed:
C) business method
Note: There *may* be more than one correct answer!
Originally posted by Kathy Sierra:
Q1: Which three are true about transactions in EJB?
A) EJB 2.0 supports nested transactions.
B) EJB 2.0 allows you to specify isolation levels.
C) Message-driven beans must not use bean-managed transaction demarcation.
D) Entity beans must not use bean-managed transaction demarcation.
E) Stateful session bean state will not be rolled back if the transaction rolls back.
F) Stateful session beans that start a transaction must complete the transaction before ending a business method.
G) A message-driven bean must commit or rollback a transaction before onMessage returns.
Q2: Which two are true about bean-managed transaction demarcation?
A) A transaction used by a BMT bean MUST have been started by the bean.
B) The caller's transaction will be propogated into a BMT bean.
C) Transactions in a BMT bean do not propogate when the BMT bean calls a method on another bean.
D) A bean cannot use both CMT and BMT together.
E) BMT beans must not specify transaction attributes.