>
> In theory, I think you're right; in practice I think you are
> naive. I believe that you are assuming error proof software. If the
> application properly uses threads and synchronization, the JVM
> doesn't have any serialization/synchronization issues in its
> implementations, and the EJB vendor hasn't introduced other
> serialization issues (which I know is not true); I believe you still
> have a problem.
This is to the point. VM code is still far from error proof. We have
introduced a synchronization cost. Each memory caches (Java Object
Memory) view of a persistant object is stable (the PCA has ACID
properties). It does not change until you hit a transactional edge. In
order to achieve this, you need to synchronize everyone's view. But,
this technology has been in development/refinement for about 17 years.
It is very effecient. The alternatives are to use OTS or distributed
tx services (much slower) or to accept that you'll have cache coherancy
issues.
What exactly do you mean by "serialization issues"? In terms of
persistance services, this could have many meanings.
I haven't seen anybody coming forward and saying that
> they've kept an EJB site with a single JVM up and running
> continuously for a year and never restarting the JVM.
exactly!
>
> Also, if the dispatching software is sophisticated it may be
> able to detect that the JVM is about to fail (e.g., increasing memory
> usage above a threshold), redirect new traffic to a different JVM,
> and bounce the JVM.
We roll JVMs in and out of service. We do redirect traffic to different
JVMs in the pool.
Kirk
===========================================================================
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".
