Hi,

We have these requirements for a component
1) The data held in the component is not stored in a table (mainly because the data changes far too quickly, to be stored and retrieved from a database)

2) The component might be accessed by multiple clients (meaning that 2 clients may be required to connect to 1 instance and another third client may be required to connect to a different instance). Please note, this is not a direct 1 instance per user situation.

How could we model this component?

We’ve been able to think of 2 possible ways-

a) A Stateful Session Bean with the bean’s handle stored in a table (OR) held in memory. Whenever there is a request for this component, the appropriate handle would be fetched and the component can be accessed.

- The inherent drawback of this approach is that two simultaneous requests to the same bean instance is not allowed unless the bean is invoked with a transactional context, because stateful beans do not allow concurrent access.

b) A BM Entity bean with no persistant data and not mapped to a database table, the bean’s handle stored in a table (or) in memory. Whenever there is a request for this component, the appropriate handle would be fetched and the component can be accessed.

- The problem with this approach is that a unique primary key field needs to be supplied. Also, the ejb callback methods load/store may be called adding to the burden.

Now there's another potential danger that the handles stored in the database (or) in memory may not be of use, if the bean gets passivated. Probably, neither of these is a totally foolproof approach!

Does anybody have a better suggestion?

Thanks. . .Ram

Hi Ram-

A quick note about concurrent access to stateful sessions beans. Technically, in the EJB 2.0 specification the requirement that stateful session beans only be accessed by a single thread at a time has been removed. There is a footnote in section 6.5.6 of the public final draft of the EJB specification:

"If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client [4]"

[4]: "In certain special circumstances (e.g., to handle clustered web container architectures), the container may instead queue or serialize such concurrent requests. Clients, however, cannot rely on this behavior."

WLS 6.0 supports both behavior. By default, concurrent requests will have a RemoteException thrown. However, you can enable the <allow-concurrent-calls> tag in the weblogic-ejb-jar.xml file to queue up your stateful session calls. This might relax your design a little bit and allow you to redesign your a) scenario.

Also, I think your b) scenario would work with an application server that does exclusive in-memory locking. This would allow concurrent calls to the entity bean, but serialize access between transactions. I think it might work for you.

Tyler

Hi,

A consolidated response to the previous comments-

Thanks Tyler, for pointing out that stateful instances now optionally allow concurrent access.

Regarding Ravi''s comment, it is clustered. Anyway could you please elaborate.

As for Paul''s remark, I could not possibly use a singleton class simply because I have more than 1 such instance and -

"2 clients may be required to connect
 to 1 instance and another third client
 may be required to connect to a
 different instance".

What do you people think about

-using ejbHandle to access the beans, and the potential passivation problem that this approach could cause?

-the second approach of using bean managed EB without mapping to a database table?

Thanks...Ram

Well, if you use an application server that provides exclusive in-memory locking to your entity beans, then implementing your solution as a BMP bean will work. However, you will get the exact same memory behavior as if you were using concurrent stateful session beans. The only issue is with the entity beans, you will have to deal with the ejbLoad() and ejbStore() methods being invoked.

Tyler

Well, if you use an application server that provides exclusive in-memory locking to your entity beans, then implementing your solution as a BMP bean will work. However, you will get the exact same memory behavior as if you were using concurrent stateful session beans. The only issue is with the entity beans, you will have to deal with the ejbLoad() and ejbStore() methods being invoked.

Tyler

if u are not using a cluster then probably a simple java approach could help you

Use a singleton class to model the shared resource, and depending on the requirement of the clients, you either use a stateful or stateless session bean to access the singleton object.

Hope this helps

Paul