seemapanth Joshi

Any reason you can't use scripting in here.

Here is What I see:

the jdiscuss questions asks:

client has just called a business method on an entity bean..

and if you would open the spec page 132 remove protocol, it says:

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.

the business method here could be the accessor method.

and as far as the HFEJB it says:

Client calls remove on a bean that has already been removed

and if you check in the list there is a big thread going on titled "System Exception Confusion " and about 23 more threads (if you search on page 559) that discuss this page and scenario from HFEJB:
https://coderanch.com/t/161147/java-EJB-SCBCD/certification/System-Exception-Confusion

I have my own confusions on exceptions and I am trying to clear them up following them and more similar thread....I would advice you to join the group.....
[ August 23, 2005: Message edited by: seemapanth Joshi ]

I have been thinking about the point #4 made in this sharpen exercise and looking around for some answers and so am pulling this thread back again because I saw total of 9 threads that talked about the issue and I am still not sure what can be considered definitely as the correct analysis. What Philippe Maquet mentioned in this topic is true or not?

Philippe Maquet:

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

For the point #4, one would deduce that NotSupported indeed is the riskiest from Bharat Ruparel's great real-life example.

I wish I could get a raise of hands to just get on the level with what everyone thinks about this issue.
[ August 23, 2005: Message edited by: seemapanth Joshi ]

Hello Ashok & Amit,

Ashok:

CMP can't propogate into BMP

That is true but in this case the txn. is not propagating back but is running in the same txn. that it received from BMT and is affecting it by calling setRollbackOnly.

Amit:

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.

I think the same way, but I just wanted to know how would the getStatus() return the txn. rolled back status.

if a method call is made from BMT Bean with Txn attribute as "required" to a CMT bean method again with txn. attribute set to "required". Then the CMT bean calls context.setRollbackOnly(). How would the BMT UserTransaction.getStatus() call know that the txn. has been set for rollback, if it is made.

Yes !. check out the link

http://java.sun.com/products/ejb/docs.html

I hope this is what you are looking for.

This is the process of thinking out aloud and please tell me if the following explanation in support for the original answers are correct.

1. This code might be MDB.
2. if it is MDB, it is Bean Managed.
3. So call to setRollbackOnly() itself will throw an exception IllegalStateException but in case of MDB, it will be logged.
4. And since the exception is System exception, it would prevent the method from successfully completing. Spec page 377. And thus container will ensure that rollback occurs.
[ August 14, 2005: Message edited by: seemapanth Joshi ]

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?

Yes, this tag can be applied for transaction attributes too, as per the DD DTD.

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?

Yes, they are java.rmi.RemoteException and java.ejb.EJBException for remote and local clients respectively. Spec Page 359.
[ August 11, 2005: Message edited by: seemapanth Joshi ]

The best thing about HF is that it is funny

There is one more good thing about headfirst, apart from being funny it also makes complex things look very simple. I guess the authors have done a splendid job on that and thats another big plus.

Rahul,

Your point number 1:

1. What are the scenarios where there can be multiple clients that can arrive in a single transaction?

I lack the market experience to relate to a real world example of such a scenario. But according to the spec this could happen if there are intermediary objects or programs in the transaction call-chain. This is same as what you have referred to:

a bean calling other bean for some services in a same transaction.

For point number 2:

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.

The specifications are probably asking you not to do exactly that. It come under "Client's responsibility" and it says:

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]

Spec: Page 449

Does that sound like a logical explanantion???

[ August 05, 2005: Message edited by: seemapanth Joshi ]
[ August 05, 2005: Message edited by: seemapanth Joshi ]

Keeping in mind the Connection is created in/retrieved from a ConnectionFactory...

According to the specification you can get multiple connections from same resource connection factory object as you are doing in your abstract sample code. The point that you are making is I guess that since you are getting a new connection from the connection factory in the method call itself would the connection retrieved from this connection factory be affected by the rollback/commit. Spec 421-422

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.

I don't see that how would whether you create a new connection or use an cexisting one would affect the transaction management. Except I would like to know if <res-sharing-scope> will have some role to play if it is defined as Unshareable.

Am I making sense here?

In that case the would not the answer be "yes", because setRollbackOnly() marks the "Current" transaction for rollback.

Also It would very much depend on what exceptions you are catching, because in case of system exception the container will automatically set the transaction for rollback. The "Current" one.

I think it has got something to do with what is explained in Page 545. Please read on and tell me if that is so. And after that I think if you could refer to page 59 of specification which states that:

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.

Whoa...I think it depends on lots of things. There is one whole chapter on exceptions and a separate one on transactions.

But first thing first, If you are going to catch "Exception e" and if you have a book called "Head First EJB" then the you can turn to page 544 and read on. This here is what they (the authors) are warning against is eating it up the runtime exceptions too.

It says in the specification that:

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.

Page 450

And As I can infer that means that the calls to getCallerPrincipal() should be the same. So I think you will not deem the third option "c" as true because it is not complete i.e. it should say with same security context or not. Does that sound like correct explanantion?. I am no expert here and so please do tell me.