client has just called a business method on an entity bean..
The Container must detect any subsequent attempt to invoke an accessor method on the removed entity object and throw the java.rmi.NoSuchObjectException if the client is a remote client or the javax.ejb.NoSuchObjectLocalException if the client is a local client.
Client calls remove on a bean that has already been removed
1) Of the six transaction attributes, which one (or ones) must NOT be used by a bean that calls getRollbackOnly() or setRollbackOnly()?
Answer = Never
In the specs p. 180, I read : "The getRollbackOnly and setRollbackOnly methods of the EntityContext interface should be used only in the enterprise bean methods that execute in the context of a transaction. The Container must throw the java.lang.IllegalStateException if the methods are invoked while the instance is not associated with a transaction."
So I had added to Never : Supported and NotSupported
CMP can't propogate into BMP
I still think calling setRollbakOnly should rollback the same transaction for BMT also and UserTransaction.getStatus() should give you back rollback status b'coz we are working on the samx Txn.
B. In HFEJB, page 582, says that the <method-intf> tag can be used to differentiate methods with same name in component and home interfaces, regarding security access. Can this tag be applied for transaction attributes too? Or if the same method are used in both, component and home interfaces, the transaction attribute must be the same?
C. Page 552 of HFEJB says that TransactionRequiredException and TransactionRequiredLocalException are thrown when you call a method with 'Mandatory' attribute without having the caller a transaction active. Which exception is thrown if you call a method with attribute 'Never' from a client with an active transaction? Is there an equivalent exception?
The best thing about HF is that it is funny
1. What are the scenarios where there can be multiple clients that can arrive in a single transaction?
a bean calling other bean for some services in a same transaction.
2. In context to above, a bean can change its security context by using the <run-as> element in DD and becoming a different principal than the calling client�s principal.
This section defines the rules that the EJB client program [B]must follow to ensure that the security context passed on the client calls, and possibly imported by the enterprise bean, do not conflict with the EJB Server�s capabilities for association between a security context and transactions.[B]
Keeping in mind the Connection is created in/retrieved from a ConnectionFactory...
Invoke the appropriate method on the resource manager connection factory to obtain a connection to the resource. The factory method is specific to the resource type. It is possible to obtain multiple connections by calling the factory object multiple times.
Because session objects do not have primary keys that are accessible to clients, invoking the javax.ejb.EJBHome.remove(Object primaryKey) method on a session results in the javax.ejb.RemoveException.
If transactional requests within a single transaction arrive from multiple clients (this could happen
if there are intermediary objects or programs in the transaction call-chain), all requests
within the same transaction must be associated with the same security context.