On Wed, 14 Jun 2000, Tim Shaw wrote:
> Perceived wisdom (spec) is that Singletons are not allowed/possible with
> EJB.
>
> I have a number of tables containing 'static' data - mainly lookup tables
> but some very complex mappings. Static here implies non-volatile over a
> Client session (or longer). These data are loaded into a client when the
> client logs on. I don't want to keep all this data hanging around as EB's
> (c. 1000 logins/day) but I do want to minimise the startup overhead.

Hi Tim --

I am pretty much a beginner at EJB, but this sounds to me like exactly
what a session bean is for?  The container will allocate a number of
them, they'll all be initialized once, when you can grab your static
data out of the database, and as clients come and request the session
bean, they get handed an instance out of the pool.  You have to
initialize k > 1 instances, but that's better than N where N is the
number of sessions during the lifetime of the container!

Since you sound like you know your way around this stuff pretty well,
you can maybe tell me what I'm missing?

Regards,

        Gary

> If I have a (normal Java) class with a static method (getStaticDataObject)
> which creates the object if it doesn't exist and returns the object (which
> can then be queried for the static data), I have a Singleton pattern. The
> object would need to be held in a static variable - also a no-no for EJB. I
> would expect the object to load/convert the data using JDBC rather than
> EB's.
>
> If the client initialisation code (SLSB) calls this static method, the VM
> will contain the data (within the class/object). If another client is
> initialised in another VM, it will get a different object, but the same
> data. If the class is garbage collected, the next time it is used, it will
> have to re-initialise itself - and get the same data.
>
> Worst case is that the initialisation is done for each Client login - best
> is that it is done once only. Consistency would need to be controlled
> 'outside' the AppServer - but it could also be coded into the above
> mechanism using checks and reloads as required.
>
> Is this a special case, where a Singleton _is_ appropriate - or a) am I
> missing something b) is it just 'not allowed'?
>
> Any other suggestions gratefully received.
>
> Thanks
>
> tim
>
> This e-mail, and any attachment, is confidential. If you have received it in error, 
>please delete it from your system, do not use or disclose the information in any way, 
>and notify me immediately. The contents of this message may contain personal views 
>which are not the views of the BBC, unless specifically stated.

Yeah, pretty confidential ;)  (I whispered the reply, honest!)

>
> ===========================================================================
> 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".
>
>

===========================================================================
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".

Reply via email to