>> > In particular, I'm wondering if static data can be moved into a utility
>> > class which is created by the EJB bean code, and therefore get around
the
>> > static restriction.
>>
>> We do just that. It works with several EJB servers we have evaluated.
>> We use singleton lookup tables of read only data implemented with static
>> instances.
>
>Marc San Souice:
>This works great within a single JVM. If your 2000 users are being
>load-balanced across 20 JVMs, each VM will have its own local "singleton".
>This may be OK for your application, but be aware that this kind of
>singleton isn't visible to all application instances serving all users.
>
>Rickard �berg:
>Then again, with the above knowledge you can assume that if you do not
>use clusters, and you never redeploy your bean, you should be fine using
>statics :-) But then again, you might not want to *depend* on that if
>you want to upscale your app later on. ;-)
I think the point is clear now. It is possible to use "easy" singletons with
static instances with the limitations enumerated above.
Distributed-clustered-load balanced-failoverized deployments
should use RMI-CORBA-JNDI singletons unless the data never changes.
For instance, a state look-up table: get the state name from it's key, could
use easy static singletons.
Regards
Javier Borrajo
www.tid.es
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
