Ian McCallion wrote:
>
> Although Mark is (of course!) technically correct I am less convinced than he
> that all servers will support this optimisation and I certainly don't believe it
> could be mandated in the spec that the data must available for the next client
> of the bean. (How long would the data have to be kept in order to conform to the
> spec? What about designs which pool skeleton beans across multiple bean types?).
>
> In any case, that is not the issue. Quite simply, (ab)using stateless session
> beans for this purpose is wrong. Server algorithms for reuse of stateless
> session beans will be designed to help optimise SERVER resources, not Jon's Java
> Library (JJL) resources. So depending on the workload there may be many more
> stateless session beans than JJL needs or wants resulting in excessive memory
> usage. Or they may be freed up very frequently resulting in excessive JJL
> initialisations.
>
Either the session bean or resource manager solution could be
appropriate depending on the details.
Jon's scenario is a good example of why servers should consider
providing caching options that take application resource issues into
account.
Delivering a library as a resource manager does provide a high degree of
control over resource usage; however, it will be considerably more
complex to implement and deploy. The current work on the Connector JSR
will allow this code to be portable but it will not make it as easy to
develop and deploy as a component.
> Implementing JJL as a resource manager is the right way to go, and the J2EE
> connection framework defines (will define) how such a resource manager should be
> accessed. Using it you will be able to optimise the number of copies of your
> library as you see fit.
>
> The requirements are out there for many different sorts of JJL, so you are not
> alone. But until the connector framework is available could you use non final
> static to hang copies of your initialised library from?
>
> Ian McCallion
> CICS Business Unit
> IBM Hursley
> [EMAIL PROTECTED]
> Tel: ++44-1962-818065
> Fax: ++44-1962-818069
>
> ===========================================================================
> 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".
