Jean-Baptiste,
<vendor>
Although it does not achieve exactly what you want, I am fond of
making the default entity transaction attribute be "Mandatory".
This serves two purposes:
1) It enforces the general principal that entities should only be
used by client running in a transactional context. This provides
the container the ability to cache instances for the duration of
the transaction, thereby avoiding the performance problems
associated with loading and storing each entity on every access.
2) If your clients avoid demarcating transactions themselves (which
they probably should, for the most part) and instead rely on
container-managed transactions, then as a side effect you are
disallowing clients from accessing these entities directly.
Obviously this is not a fool-proof solution. If you clients are
smart enough to know to access the entities from a client-demarcated
transaction, they still can. But then these clients might also
be sophisticated enough to understand how to use entities properly,
and therefore either don't need to use the fa�ade, or alraedy know
to always use it.
Just a thought: please no flames!
</vendor>
-jkw
Jean-Baptiste Nizet wrote:
>
> It's often a good design to have a session bean acting as a fa�ade to one or
> several entity beans. This allows a good transactional behaviour, some
> validations in the facade, additional security if needed, and more reusability
> for the entity bean.
> However, the entity bean sees its fa�ade session bean as any other client. Is
> there a way to ensure that the bean (or some methods of the bean) is always
> accessed through a fa�ade, and not directly from the client?
>
> JB.
>
> --
> Jean-Baptiste Nizet
> [EMAIL PROTECTED]
>
> R&D Engineer, S1 Belgium
> Kleine Kloosterstraat, 23
> B-1932 Sint-Stevens Woluwe
> +32 2 200 45 42
>
> ===========================================================================
> 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".
