krishnakumar ramamurthy

Greenhorn
+ Follow
since Jan 10, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by krishnakumar ramamurthy

A query language only allows one to query thing and not to insert, update and delete stuff.[/B]



SQL is also a Query Language!!!
In the second case the client is not calling the getprimary method the session bean is calling it in one of its method. The second call may not be in response to client's call.

It seems strange that a stateful session bean can access it's clients security info in the ejbActivate and ejbPassivate but an entity cannot.

I surpose the entity is not associated with its client at that point. But it does make things more confusing.



Yes. The entity is not associated with its client at that point. ejbActivate() brings the entity from the pool to the ready state.



Just one last question: It is impossible to access a resource manager or another bean without being in a transaction? (Does this depend on the transaction attribute of the accessed resource or bean?)



You can access another bean without being in a transaction. In ejbcreate() of stateful session bean you can access other beans.
According to the spec, access to Enterprise beans are not allowed from methods where there is no transaction context or client security information. in ejbcreate the stateful beans have access to client security whereas stateless beans do not have.
There is a good explanation for this. And remember the SessionContext is still available from those methods.

https://coderanch.com/t/158485/java-EJB-SCBCD/certification/beanness-stateless-session-bean.
if you have a single instance of the class with many threads accessing them then having unsynchronized setter methods will cause problems.
[ January 10, 2005: Message edited by: krishnakumar ramamurthy ]
I am not familiar with orion. But it does not need to be pointed to the source code for line numbers. The jvm when run interpreted will give the line numbers in the stack trace but when the piece of code is compiled the stack trace will not show line numbers. You can set the jvm to run in interpreted mode but that setting is jvm dependent.