Robert,
perhaps I misinterpreted the nature of the 'transient data' you refer to. I
usually mark attributes transient if the algorithm is essentially stateless
and the transient attribute is used to cache intermediate results which may
(or may not) be of use to other processes. If this is your case (and if your
EJB implemetation supports this) you could set the bean timeout period long
preventing the singleton's removal by the server.
Alternatively, you could of course give the singleton persistent state, so
it wouldn't matter if it were temporarily removed from the server. Which
method is most suitable for you application will depend on the volume of
data being cached and the number (and frequency) of clients accessing the
bean.
Donald.
> >
> > One technique we've used succesfully to share 'session beans' between
> > multiple clients is to construct entity beans, with no persistent state,
> > using well known primary keys. Singleton's can easily be
> constructed in this
> > manner by declaring a pk with no attributes.
> >
> > regards,
> >
> > Donald.
> >
>
> But where does the transient shared data go, when the container decides
> to remove your entity bean instance from memory? Maybe I'm missing
> something but wasn't the problem sharing transient data? Maybe I
> misunderstood the spec but I thought that there was no way to influence
> whether a bean instance is kept in memory or not? If that is correct the
> so-constructed Singleton would lose its state when being removed from
> memory.
>
> Please correct me if I'm wrong.
>
> Regards,
>
> Robert
>
>
===========================================================================
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".
