>>>If isolation is left to the database, how does the WebSphere container
>>>provide isolation of EJB object state?
>>>Regards
>>>Alex Thomas
>
>>That's the point. The WebSphere container in itself doesn't provide
>>that isolation. It doesn't have to. It simply honours the session bean's
>>transaction demarcation (TX_BEAN_MANAGED or TX_REQUIRED) and transaction
>>isolation (TRNSACTION_SERIALIZABLE) requirements by delegating them to
>>the RDBMS/OODBMS.
>I might be missing something here, but that seems rather dumb, since it
>makes it impossible for the app.server to cache Entity data. Why? Well,
You might consider it dumb but are you saying serialising access to the
shared domain objects (as done by WLS) is smart? Does it help concurrency?
As for instance data caching, there is no such requirements in the EJB
spec and IMO for good reasons:
1) Cached data is only good as long as it's up to date. Not likely in
multi-VM or transitional systems with legacy apps updating the DB directly.
2) The best place to cache instance data is probably the DBMS cache
3) You can always buy an ODBMS plugin for the container
>The conclusion is that it is impossible to use
>* optimistic concurrency control in the container container
>and
>* caching of Entity data
>and
>* SERIALIZABLE isolation level in the DB
>So, for applications that rely on caching of Entity data for
>performance, using a container with optimistic concurrency control will
>not be a good idea.
IMHO applications that rely on caching of Entity data should use RDBMS cache
or add ODBMS plugin to the container or use a different technology
altogether,
rather than compromise on container managed pessimistic concurrency control.
>/Rickard
Regards,
Hamid
===========================================================================
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".
