Is there a reasonable substitute for static variables in J2EE?
0 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Boris_Shpungin
Posted On:   Thursday, September 6, 2001 06:52 PM

For example, suppose I want to count the number of currently allocated session beans, and report this count to some GUI in real-time. I don't want to install, configure and administer a database just so that I can have an Entity Bean to keep track of this count. Plus, it wouldn't exactly fit the bill, since the count should be reset to 0 when the server crashes and comes back up, not restored to its old value. A Message Bean also sounds too heavy-weight for such a simple task. Plus, what if I want to do something like limit the count to some hard maximum? Suppose I want to put into my session beans' ejbCreate() method something like the following: if (getSessionCount() > LIMIT) {    More>>

For example, suppose I want to count the number of currently allocated session beans, and report this count to some GUI in real-time.


I don't want to install, configure and administer a database just so that I can have an Entity Bean to keep track of this count. Plus, it wouldn't exactly fit the bill, since the count should be reset to 0 when the server crashes and comes back up, not restored to its old value.


A Message Bean also sounds too heavy-weight for such a simple task. Plus, what if I want to do something like limit the count to some hard maximum? Suppose I want to put into my session beans' ejbCreate() method something like the following:

			
if (getSessionCount() > LIMIT) {
throw new RuntimeException( "Connection limit exceeded" );
} else {
incrementSessionCount();
}


The two *Count() method calls would obviously have to reside within some block that is synchronized on the global count. If I keep the count in a Message Bean, I would have to follow an algorithm kind of like this:


  1. MyMessageBean = context.lookup( name );
  2. 					
    do {
    requestLock( MyMessageBean );
    if (gotLock( MyMessageBean )) {
    break;
    }
    wait for some time (e.g. exponential backoff)
    } while (true);

  3. 					
    if (getSessionCount( MyMessageBean ) > LIMIT) {
    throw new RuntimeException( "Connection limit exceeded" );
    } else {
    incrementSessionCount( MyMessageBean );
    }

  4. releaseLock( MyMessageBean );


In other words, "simulate" Java synchronization by using my message bean as a lock manager. But even this is bogus, since what would happen if a bean obtained the lock, then crashed? The message bean would remain locked forever, and the whole application would hang soon thereafter!


Before J2EE, it used to be so simple! I would just have a static counter, and a static lock variable. I would synchronize on the static lock and then do stuff, increment counter, etc. But since J2EE outlawed static variables, it would seem that now such a simple algorithmic requirement cannot be satisfied! Or am I wrong?

   <<Less
About | Sitemap | Contact