> Chip Wilson wrote:
> >
> > [Chip Wilson]
> > If a business method does not modify an entity, then the method
> > should not require a transaction and one should not be begun, either
> > explicitly or declaratively. No transaction commit, no call to
> ejbStore.
> >
>
> This seems questionable for two reasons.
>
> 1.. It's, more or less, the assertion that you never want to
> acquire a read-lock unless you're writing something back out to
> the persistent storage mechanism. This seems the most common
> case :-), but is it universally the case ? I can see cases where
> you want to guarantee that data won't change underneath you.
[Chip Wilson]
Yes, and in those cases you do need a transaction. Beware of long-running
transactions, as these are almost certain to be performance bottlenecks.
The original post specified that changes were not being made, and asked if
ejbStore could be avoided. It can, if there is no transaction.
> 2.. Business methods can be invoked by other business methods.
> While the invoked method might not *require* a transaction, it
> might still *support* them (for the reason in 1). In which case,
> the "should not require" part of the answer doesn't suffice to
> avoid the overhead.
[Chip Wilson]
The container will call ejbStore on every entity bean touched by the
transaction being committed. A decent O/R mapper should be able to
determine whether anything has actually changed in the entity, and should
only generate SQL for the delta, thus avoiding most of the overhead of
calling ejbStore.
In general, I favor placing transaction control in session beans rather than
entity beans, so in general I declare all entity bean methods as either
"supports" or "mandatory".
===========================================================================
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".
