Ian McCallion wrote:
>> In any transaction, including distributed ones, you should see the
>> committed state plus the effects of changes made earlier within the
>> same transaction. Outside the transaction you should only see the
>> committed state.
>
>Agree 100%. But only if we can agree to exclude the examples Chip Wilson
pointed
>out where two beans of different classes instantiate the same database
data. If
>we exclude these situations, we are saying that for the duration of a
>transaction, a bean's state is pure WORKING STORAGE which seems emminently
>reasonable to me. If we insist on including them then:
Unfortunately, your recommendation is quite impractical with normalized
databases and/or large granularity beans (where dependent data rears its
ugly head). Let's not forget that the idea behind using an RDBMS for backing
store is to be able to use the data for other purposes as well. Well
designed database schemas are especially unsuited for the sort of object
encapsulation you are talking about.
Moreover, the problem also applies when using only a single bean (only one
class) with multiple instances in the same transaction.
>In other words encompassing Chip's examples within your consistency rule
>violates encapsulation, performs like a dog and is useless to the
developer.
>(Flogging ended. Is the horse dead yet;-)
Chip's points are even more valid now. Your consistency rules will make your
db architects very unhappy :-)
Imre Kifor
Valto Systems
===========================================================================
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".
