>A couple of questions.
>
>1) Re. Stateless Session Beans: Is it correct to draw an analogy
> with Singleton's ? It seems obvious, given that any instance
> of a Stateless Session Bean is the same as any other instance.
> If I want to rewrite a particular Singleton as an EJB, and it
> does not preserve state information across method calls, can
> I implement it straight away as a Stateless Session Bean ?
> Any "gotcha's" to be aware of ?
No static variables and no private constructor allowed, so it is not a
Singleton.
>2) Let's say I want to implement DB transactions, but my EJB Server
> does not support Entity Beans. In that case, am I forced to
> implement transactions on my own, by using Stateful Session
> Beans, and BMP, with all methods deployed as TX_BEAN_MANAGED ?
Transactional stateless session beans are OK if the transactions
do not require a conversation with the client, i.e. it is just a
request-response affaire.
If a conversation is required you must use a statefull session bean but
there is no need for TX_BEAN_MANAGED, the container deals with
the transactional behaviour. The container cannot passivate a statefull
EJB if it is involved in a running transaction, nor can the user invoke a
non-transactional method.
Regards
Javier Borrajo
I+D Spain
===========================================================================
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".
