Help coderanch get a
new server
by contributing to the fundraiser

Miki Muzsi

Ranch Hand
+ Follow
since Jun 23, 2003
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Miki Muzsi

Parshant, i had the same question: see here

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.

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.

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"..


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.

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.

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.

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


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.

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 :-)

ok. I agree. Tricky question

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

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 ...