Throttling implementation for EJB methods

Discussions

EJB programming & troubleshooting: Throttling implementation for EJB methods

  1. Throttling implementation for EJB methods (4 messages)

    I have a stateless session bean which has set of methods. For example
    MyStatelessBean{
    void method1() throws ThrottlingException;
    void method2()ThrottlingException;
    }
    I would like to count the number of calls made to each method. And also, if the count exceeds throttling limit, I want throw an exception to client .

    I am thinking about the following options
    1. Having a collection of single Objects (one for each method).
    Problems are :
    It is against EJB rule (static variable update)
    Performance issue when the multiple client tries to access a method, because of synchronized update
    2. Writing a stateful session bean.
    which would be the better solution to this problem?
    Or any other solution to this problem?
    FYI: I don’t want use entity bean , because I require an database to persist the count.
    Thanks in advance
    siva
  2. Sorry , it is not “single Object”. It is singleton object
  3. What do you mean by "static variable update"? It sounds weird that EJBs wouldn't be allowed to use a singleton class' services?

    You shouldn't use a static class variable defined within an EJB class, but I believe you're allowed to use an external singleton class, which keeps count of the method calls.
  4. Thanks for your the feedback
    I thought of having another class(ThrottlerCollection) that will have a static variable (hashtable) to store the collection of Throttler instances.
    So first call to method1 will create an instance of the MessageThrottler and next calls to method1 would get the existing instance and update the method counter.
    The Problems i see here are
    1.Static variable to store the collection of throttler
    2.Synchronized Updating method counter
    Both are in separate class.
    Are they against EJB rule?
  5. The EJB spec forbids static members for two reasons

    1) If you need to update that static member that requires the use of thread synchronization primitives which are forbidden. The spec writers assumed (and probobly well) that most developers will have problems doing this right and
    2) That singleton patterns dont work in most EJB servers because those servers use custom classloaders, and the singleton would only be a singleton within the same loader.

    Therefore no singleton patterns which use static members will work predictably.

    You're best bet is to use an EntityBean. I know the performance of that is going to suck big time, but its the only 'legal' way.

    You're other choice is to just ignore that its illegal and use a singleton. But be careful, you may not get what you expect in alot of EJB servers.

    Dave Wolf
    The Scupper Group
    dave@scuppergroup.com