Yes, the container can not assume that various resources are bound (looked
up) within the scope of the transaction where they will be used (like a
bean-managed EJB or a servlet calling the UserTransaction). The connector
specification even requires (which I would say is a bit of over kill, but
never the less) the container to re-associate connection handles (like a
JDBC connection created by looking up a DataSource and calling
getConnection) if it happens to be used in a different transaction then it
was originally created from. With other words - you could store not only a
DataSource in a SLSB instance field, but also an actual Connection, JMS
Queue/Topic connection or any type of connection handle obtained from a JCA
1.0 compatible resource adapter.

It should also be fine to store home interfaces in SLSB instance fields. I
suppose it is good practice to declare such fields to be transient. I'm not
sure to what extent this is also valid for CMP 2.0 entity beans.

/Johan

Den 03-06-10 17.10, skrev "Alex Paransky" <[EMAIL PROTECTED]>:

> We have all gotten used to resolving homes of related objects and other
> resources in either ejbCreate/setSessionContext (for Session beans) or
> in setEntityContext (for Entity beans), however, does the same thing
> apply to actual Entity bean references as well?
> 
> For example, suppose that there is a set of mostly �static� (never
> changing) Entity beans in the system. Things such as GenderEntityBean
> (Male, Female or Unknown). Further suppose, that some stateless Session
> bean needs to use these entities. There are many different ways that
> these Entities can be obtained:
> 
> 
>  1. Look them up in the function which uses them
>  2. Look them up in the setEntityContext of the Session and �cache�
>     them as member variables
>  3. Call a helper Session bean to retrieve the Entities (helper
>     Session bean could either do 1 or 2 above)
> 
> 
> The same can be said if another Entity bean needs to do similar caching.
> 
> 
> Which, if any, of the above methods is recommended. If options 2 or 3
> are used, will this work correctly with transactions? Will the cached
> object �enter� an existing transaction when it is first referenced from
> such a transaction.
> 
> 
> Thanks.
> 
> 
> --
> -AP_
> http://www.myprofiles.com/member/profile/apara_personal
> http://www.myprofiles.com/member/profile/apara_business
> 
> ===========================================================================
> 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