Richard Crouch

+ Follow
since Nov 03, 2005
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 Richard Crouch

Pretty much bang on the nail there.

Yes I want to have SLSB that will act as a router by being able to call the SFSB or not, dependent on whether they need any additional static info from the SFSB. This should prevent the bottleneck that I am getting at the moment as multiple requests will just generate multiple "router" SLSBs. Some of which will not require any additional information from the SFSB and the others will only tie up the SFSB for a minimal amount of time while getting the info they need. Obviously the problem with my current architecture is that the SFSB is locked until the whole transaction through all the beans is processed.

Now the problem comes with trying to access the correct SFSB in this new architecture. If I generate it from the SLSB("router") then when another request that requires information off of that bean comes in, how can the new SLSB know which bean to get. Hence looking at passing around the Local reference, though this appears to not work due to it not being serializable.

I can see how this can be done, using a primary key with entity beans, but I do not wish to(and can't) use entity beans as I do not want any record mapped to my database by the beans...

Does that make it any easier to help me? sorry :-s

Cheers if you can

Thankyou for the response.

My problem here comes due to the front end that I am using. We are using a flash front end through OpenAMF remoting. This does not pass the HTTP session onto the business delegate, more importantly some, of the information stored in the SFSB we want as far into the application as possible so that it is not exposed. One way we could do it would be to grab an amount of this data from the database every time to use it to determine what info is required for the request.

This is fairly wasteful, and a waste of time. The other way considered is to rewrite a large number of our database procedures to get this data within them, and again this is far too large a task to take on, so I amstuck trying to hold each users information as far in the back end as possible.

How do I use EJBHandler, as the EJBLocal does not appear to have the method to get a handle to it? This is frustratingm, there must be some way of passing a reference to a Local EJB back to the cliet through the remote bean so that that client can ensure that it can call that same bean again?

Cheers for any help you can give...

I don't know whether to post this as a new topic or not, but the title of this thread caught my eye. I am having a problem using a Local object. To try and improve the speed that my application responds I am trying to change my app infrastructure.

At present I have a business delegate(BD) in the web tier calling a remote stateful bean from which this bean calls services on other beans and retains information required to do this. However if the BD gets too many requests in succession, as we are building a RIA, then it cannot access the stateful bean and fails the request, this causes a problem.

Top resolve this I want to set up statless beans to distribute the services, but a stateful bean to hold the required information to make the correct databas calls. However in order to maintain the ability to get the correct users stateful bean, i am trying to pass back the LocalHome element to the BD, so that every time it calls the services bean, it can pass the reference so that the services bean knows where to find the details of that user....

At present though I get

WARNING|sun-appserver-pe8.1_01|javax.enterprise.resource.corba._CORBA_.util|_ThreadID=35;|"IOP00100006: (BAD_PARAM) Class com.sun.ejb.containers.EJBLocalObjectInvocationHandler is not Serializable

Can anyone suggest why I am and what I can do to resolve the problem....