Miki Muzsi

Parshant, i had the same question: see here

Miki

It hurts in the sens that threads need to wait! So if you have a lot of big methods all running in (say) different transactions, multipls threads can not (hurt) execute concurrently.

Miki

Search in this thread and you will find the answer :-)

The book says that Using reflection API shold be avoided to ensure bean portability across all EJB 2.0 containers.

I think the question is not clear, and strictly speaking it is wrong. Reading the spec I understand that you should not use reflection API in case you want to access information that the security rules of Java language make unavailable (see pg. 495).

But if I have a value bean, who's attributes are changing quite ofent, I see no reason why should't I use reflection to get it's public accessor methods.

Miki

sawan, after studying your post I finally got the idea :-). I am definately not native english speaker but I find the formulation at least very strange! Why could't she just say: "Environment entries of the same enterprise bean type can have distinct values" instead of .. "be unique for instances"..

Thanks,

Miki

sawan , thanks for creating such a test. I will create as well later this week but since I have the exam tomorrow I don't have time now.

However I must say I am surprised that web logic did not throw an exception or so for the test you read. According to the spec the only possible transaction attributes ffor a SB that implements the SessionSynchronization are: required, requiresnew and mandatory. )pg. 352. It is true the spec doesn't mention what should happen if this conditions are not met, so maybe that is why web logic allows it.

Still, this explains the original problem. Thanks both of you for the input.

Miki

The following code is considered to be incorrect:

Context initCtx = new InitialContext();
TaxHome taxHome = (TaxHome) PortableRemoteObject.narrow(initCtx.lookup("java:comp/env/ejb/tax"), TaxHome.class);
Tax tax = (Tax) PortableRemoteObject.narrow(taxHome.create(), Tax.class);


The explanation: "Casting using PortableRemoteObject is not done for remote interfaces returned by bean methods".

I agree the component interface doesn't need to be narrowed, nor even casting is required. But I think the code is correct and runs without any problems.

Miki

I still don't understnand. What is ment by environment entries? The env entry key (jndi) or value? I read couple of times but still ... I don't understand what he/she wants to say.

Miki

sawan I think you are protecting Kathy & Bert :-)

Miki

The point is if the calling application is running in unspecified transaction context then is afterBegin() called?

and BTW sawan, the afterBegin() it is always called! spec pg 75, 7.5.3. the third paragraph from the end.

Miki

Sawan, thanks for clearing that the afterCompletion() is always called in UTC. I remember somewhere on this forum reading that it would be called without TX context.

Roger, regarding your comment:

The afterBegin() method is therefore invoked with the transaction context

I am not sure this is true. The spec says (pg 76, 7.5.6):

A session bean's afterBegin() and beforeCompletion() methods are always called with the same transaction context as the business methods executed between afterBegin() and beforeCompletion() methods

Well, what happens if the TX attribute of the business method is Never :-)

Miki

ok. I agree. Tricky question

Thanks.
Miki

Thanks Sawan.

Miki

Then why is the answer for that "not true" in HF.

Miki

Which statements about stateful and stateless session beans are true?

A.Only stateful session beans support transactions.

B.Only stateful session beans can be passivated.

C.Only stateful session beans have a 'setSessionContext' method.

D.Both stateful and stateless session beans can support overloaded 'ejbCreate' methods.

E.Both stateful and stateless session beans can implement the 'javax.ejb.SessionSynchronization' interface.

F.Both stateful and stateless session beans can have instance variable state.

Correct answer B,F.

I think D is correct answer since even a stateless session bean can have overloaded ejbCreate() method, just thet the ones having arguments will nevcer be called.


Answer F is a bit tricky: it is true that both stateless and stateful SB can have instance variables. But what is the meaning of "instance variable state"? Since stateless session beans do not maintain state ...

Miki