Hi Thomas
Does
"Since these are not legacy apps, we are able to allow database access be
restricted to a single VM."
mean you do not have failover safety? What about load balancing? Is ths done
at another service layer?
-william
-----Original Message-----
From: Thomas Alex [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 28, 2000 3:51 PM
To: [EMAIL PROTECTED]
Subject: Re: optimistic locking and deadlock (was EBs are slow)
Not wishing to prolong this exchange, but I'm not sure that the
ramifications of my earlier factoid were grasped in their entirety. The
TOPLink (and Versant) containers do not serialize access to EJB methods for
the same logical object, each method proceeds concurrently on separate
EntityBean instances, each representing the same PK. Each transaction
modifies its own copy of the object's state (which, according to other
settings, may have been retrieved from the cache), conflicts then only
(normally) being detected at commit time when the state is merged back into
the cache.
I raised the question about WebSphere because, as Rickard says, it's hard to
see how transaction isolation is a problem only for the database if caching
is used. Certainly we are developing many applications that rely on this
cache for the necessary performance, since retrieving the data and
converting it to object state is by far the biggest cost in processing one
of our transactions (which is why one might use an ODBMS of course). Since
these are not legacy apps, we are able to allow database access be
restricted to a single VM.
cheers
alex
> -----Original Message-----
> From: Lahooti, Hamid [mailto:[EMAIL PROTECTED]]
> Sent: 28 July 2000 13:25
> To: [EMAIL PROTECTED]
> Subject: Re: optimistic locking and deadlock (was EBs are slow)
>
>
> >>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?
> >>As for instance data caching, there is no such requirements
> in the EJB
> >>spec
>
> >No, but this is a valid implementation choice that is
> beneficial in many
> >cases. Why are you assuming that just because you don't like
> it, noone
> >likes it?
> >> 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.
>
> >Agreed, although the multi-VM thing assumes that the VM's share data.
> The shared data is in the database. If you update a DB record
> in one VM,
> how do you ensure a different VM's cashed bean instance gets updated.
>
> >This is not a required implementation restriction of multi-VM
> >containers...
>
> >>2) The best place to cache instance data is probably the DBMS cache
> >Why?
> Because bean instance data represents information in the
> database which is
> can be cached by the DBMS.
>
> >>3) You can always buy an ODBMS plugin for the container
> >I'm using RDBMS's most of the time.
> >Hmm.. make that always..
> I am talking about using ODBMS as a cache (see Javlin, Versant).
> You are talking about the backend datastore, different things.
>
> >>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.
>
> >Again, you are assuming that your view is the only correct
> one. I'm not
> >saying that PCC is "best", and I am not saying that OCC is "best".
>
> You said OCC was dumb. That's a generalisation for a whole class of
> application servers that use it.
>
> >They re both "best", depending on the situation. I am merely
> trying to
> >identify the various characteristics of choosing either. That is all,
> >and which also happens to be on the primary purposes of this list.
>
> >I would suggest that you try to get a wider perspective of
> these issues.
> You should practice what you preach.
>
> >Narrowmindedness is more than often a restriction than help.
> Dogma is even worse.
>
> >/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".
>
----------------------------------------------------------------------------
----
This email and any files transmitted with it are intended solely for the
addressee(s) and may be legally privileged and/or confidential. If you have
received this email in error please destroy it and contact the sender, via
our switchboard on +44 (0)20 7623 8000 or via return e-mail. You should not
copy, forward or use the contents, attachments or information in any way.
Any unauthorised use or disclosure may be unlawful. Dresdner Kleinwort
Benson gives no warranty as to the accuracy or completeness of this email
after it is sent over the Internet and accepts no responsibility for changes
made after it was sent. Any opinion expressed in this email may be personal
to the author and may not necessarily reflect the opinions of the Bank or
its affiliates. They may also be subject to change without notice.
----------------------------------------------------------------------------
----
===========================================================================
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".
===========================================================================
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".
