On Thu, 20 Jul 2000 07:25:07 -0400, dan benanav <[EMAIL PROTECTED]>
wrote:
>1) Clustering is transparent only for idempotent stateless session
>beans. (Idempotent means that the same method can be called multiple
>times without sacrificing integrity of the data. Or that calling it more
>than once has the same effect as calling it once.)
This is based on the assumption that "transparent" really is
"transparent fail-over". It is also based on the assumption that
non-transacional resources are used.
If a single server setup fails you will get an exception, and will have
to re-try the operation. Similarly, if an operation on a bean in a
clustered server system fails you might get an exception (in the case of
non-transparent fail-over) and have to re-try.
Thus, in this case there is no difference between clustered and
non-clustered, unless above assumptions are made.
>2) For entity beans no automatic failure is provided. You need to wrap
>your method calls around a try, catch(RemoteException) block and retry
>the call in a loop.
Which is the same for a non-clustered server. Where is the difference?
>4) In single server mode you can assume pessimistic concurrency is
>used. In a clustered mode you must assume optimistic concurrency is
>used.
Yes, since there is no global locking scheme in place. This is an
important difference that may have serious implications on the
applications semantics.
>5) You cannot use dbIsShared=false and take advantage of caching of the
>entity beans.
Correct, but there may be reasons in non-clustered scenarios that
disallow the use of dbIsShared. All a matter of system setup. But, the
important question is, does it impact your code? (at least that is the
impression that the original question was)
>The bottom line is that when you design your system for weblogic you
>should be thinking about clustering up front. Many weblogic designs are
>based on pessimistic concurrency. If you do not you may wind up having
>to make significant design changes afterwards.
>
>I would like to see a discussion and comparison of how other ejb servers
>handle clustering.
Indeed, such discussions would be very useful as there are many pits to
fall into.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
