Locking - synchronized

[Kris Reid]

I'm a little rusty on the EJB front and could really use a hand in a design issue.

I have a Stateless Session Bean that calls a method on a search remote server. This method can only be used once per second with the same parameter. My SSB may have a 1000 clients connected to it so it has to be throttled.

I had the brilliant idea of using a HashMap with Storing SearchParameter as the key and last search time as the value. Synchronize on this see if the SSB can search yet else wait(x) then try again. Problem is I can't get the same reference to the HashMap to every instance of my SSB.

What is the most efficient way of handling such a locking mechanism? I need something like a database but isn't that over kill?

Thanks

Kris

[Dave Wingate]

I was wondering about:

"Problem is I can't get the same reference to the HashMap to every instance of my SSB."

Is there something about a session bean that would prevent you from making the Map a static field and, thus, available to all instances of the class?

Or are we talking about beans deployed across multiple JVMs?

[Kris Reid]

Love an easy solution!

Although I remember something about not being allowed to use static members only final static members. I have done a google and the information points to that your not allowed to use them but it probably won't hurt.

Don't like the probably. Can anyone verify this?

[Kris Reid]

Apparently the problem with Static variables is they are only available in a single JVM. Since I am running Sun App server on a single processor it will only have one JVM so no problem. Right??

[Ajith Kallambella]

Static variables are bound to the class rather than the instance(s). So all SSB instances will share the same static variable. You still have to address the concurrency issues here, since multiple threads may be accessing it in a read/write mode.

[Balazs Borbely]

Originally posted by Kris Reid:
Apparently the problem with Static variables is they are only available in a single JVM. Since I am running Sun App server on a single processor it will only have one JVM so no problem. Right??

You will have problems also if the JVM uses more than one class loader. If a class is loaded more than once in different class loaders than, each class loader will have his own static variables.
And the bad news is that, all J2EE app servers use different class loaders for different deployed applications.

I see 2 possible solutions.
1. Use a 'J2EE Singleton' a regular object and bound it in the JNDI tree.

2. Use some Caching strategy implemented trough AOP. (I am not sure if it is possible with ejbs)I implemented this kind of caching strategy for Spring.

[Kris Reid]

Damn!

I will be plugging the app into a database down the track so I'll use that for the locking. The static will be good enough for short term testing.

Thanks guys