Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Srini Madala

+ Follow
since Feb 27, 2005
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 Srini Madala

Thanks Jayesh! It is interesting and makes sense to me.

Yes, we have hundreds of controller classes and they are not thread safe. I think I misstated my issue here. It is not the logged in user information that is getting swapped, but we are facing the swapping of claim information. While the user is working on a claim, all of a sudden, he/she gets another claim information on the screen. Since all controller classes are singleton classes, I think it is applicable to all types of service calls - read, update, delete etc.

So, assuming that all controllers are not thread safe, is there a way to make them thread safe at the configuration level in web.xml file without impacting the performance?
6 years ago
Thanks Jayesh for your quick response. But I did not get the concurrency issue you are referring to. Where exactly we may encounter thread safe issue in terms of session id information?

By the bye, we are using ACEGI security to handle internal users security. Not sure whether it helps in pinning down the issue.
6 years ago
Hi, We are facing a burning issue in our production environment where users are randomly kicked out to the login page and also the user sessions are swapping randomly. I am unable to figure out the root cause of this issue.

The environment:
Spring framework 2.0.6
Web Logic Server 10.3.6
Load Balancer at Web Logic Proxy server
Load Balancer between Web Logic Proxy server and Web Logic main server

Troubleshooting steps taken so far:
- Tried to troubleshoot the issue step by step. In first step to see if the issue is at the load balancer because of session stickiness is getting lost by decoupling both the load balancers to send the request directly to the main server. The issue still exists.
- Users are not on RDP Therefore sharing the same session id is ruled out
- Checked if the uesrs machines are configured to get dynamic IP address - yes it is configured to get dynamic IP address, but the interval is over 60 days. So this is also ruled out. We made sure that all users are sync'd to get the dynamic IP address on the same day
- All user browsers are configured to store cookies. Therefore URL rewriting is not kicked in.
- Made sure that cookies are not blocked at proxy or firewall.

I am scratching my head to figure out what else could be the issue. I am not sure how session is handled in Spring. I believe, WebLogic creates the sessoin and passes the session information in the header. Therefore, I don't think Spring is culprit in this scenario to store the session information at instance variable level.

To better understand how the issue is arising, we have installed video recording software and also fiddlerCap to capture information. Waiting on this information.
Can you gusys shed some light on this issue? Any pointers or clues.
6 years ago
Now this book is available at McGrawHill site
I know this is not the right forum to post the exam results, but I would like to thank the wonderful people here who responds quickly to the doubts posted. This forum really helped me to clear some of my doubts. My special thanks goes to Keerti, Amol, and Gemini. They are so active and prompt in responding to the posts.

I used HFEJB and Mikhalai's notes only for the preparation. I did mock exams using SoftSCBCD, and JDiscuss. These mock exams helped me a lot to grasp the concepts and thinking of the concepts in all the corners.

Thanks again to everyone in this forum and wish you good luck to all who are appearing for the test.
15 years ago
All the methods in EJBContext (i.e. SessionContext, EntityContext, and MessageDrivenBean) interfaces are called by only container. These methods are SetXXXXContext, ejbCreate, ejbRemove, ejbPassivate, ejbActivate etc.

The bean provider can call the methods in Home and Component interfaces. Obviously in the options, these are remove (either from home or component interface) and security context methods (such as getCallerPrincipal, isCallerInRole).

Hope this helps...
Yes Dan.. You are right. The container may create EJBObject first and then the actual bean by calling new instance(), setSessiionContext(), and then ejbCreate().

As far as stateless session beans are concerned, it is up to the container, how it creates the beans. So we can not for certain assume that the bean will be created only when client calls create method on its home itnerface..
Thanks Keerti!!! I got it now.
I too have trouble understanding it. If you want to have security at instance level, use programmatic way..

For example, we have a class called "TestBean" and a method "testMethod". Let us assume that we have granted "EmployerRole" in the DD to access this mehtod. So the caller who has "EmployerRole" can access this method on any instance of the TestBean class.

Now let us assume that we need to have security at instance level.. so we put the following code in the class..

public void TestBean implements SessionBean {
public void testMethod() {
if (isCallerInRole("AdminRole") {
} else {
throw exception...

Here how are you achieving the instance level security. How many instances of the class you instantiate, you get the same code and the same logic and is applicable to all instances...

I don't get it how it is different... Can anyone clarify it please...
One of the EJB programming restrictions is that EJB should not use Java Reflection API. Because of this, you got getEJBMetaData method in the remote home interface to interrogate the bean and know about it.

But in local home interface getEJBMetaData method does not exist. As per HFEJB on page 148, you can use java reflection to learn about the bean in case of local objects.

Whether it is a local or remote object, it is EJB only. Why can't the EJB programming restriction of "Reflection API should not be used" apply to the local objects?

Can anyone clarfiy..
Remember that stateless session beans are not tied to any specific client. The same stateless session bean can be served to multiple clients during its life period. Stateless beans go back to pool once it serves client and are ready to accept requests from other clients. But the stateful session beans are tied to a specific client. So it is created when the client calls the create method on stateful session bean home interface and will end once it served the client.

So, think about it. Why do you need to create stateless session beans when client calls create method if these beans can serve multiple clients. The container may decide to create a bunch of stateless beans during server startup for performance.

When client calls create method on a stateless session bean, the container creates EJBObject and associates it with the bean.

Hope this helps....
If you want to allow several methods being called by anyone, Can you define these methods within an unchecked element? I thought you can specify unchecked element instead of rolename for a method, not for a list of methods.

The mock exam question 2 on page 593 chose this option:

What's true about methods that should run without being checked for authorization?

A) They can be listed in the <exclude-list> element
B) They can be listed in the <unchecked> element
C) When the <unchecked> element is used, it should be placed where the <role-name> element normally occurs in the deployment descriptor
D) When a method permission relation specifies both <unchecked> and a security role, the container will use the security role.
I thought the answe is only C, but the book checked B and C.

How can you specify a list of methods in an unchecked element? Different classes can have the same method name?
I totally agree with Amol. The questions on are too vague. I just gone through this exceptions one an hour ago. I too got the same doubt.

2)if Instance didn't call setRollbackOnly, which exception is it ...this decides for what container does....for App Exceptions, container doesn't rollback Tx nor does it commit, it allows Tx to be continued.
But if its Sys exception, Tx is rollbacked.

Even if the questions says that it throws application exception, it is still vague to answer option 2. This option seems to be correct only if the method has a "RequiresNew" transaction flag. Otherwise the transaction will continue to run in client's Tx, without commit.

We are not sure what to do if such questions come in exams.
The question is regarding method declaraion in a component interface, which session bean can have the create method with parameters.

MyBean create(String name) throws CreateException, RemoteException;

The answer marked is only stateful session bean. I know that the create method with parameters can only be used for Stateful session beans, but the question is missing "public". Is it still valid? I don't want to miss a question on exam for this simple reason by take it granted that public is implied as mentioned in the HFEJB book.