John,
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. 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. The JVMs leak
memory, there are serialization issues in both the JVM and most of
the vendors' implementations, and most applications aren't bullet
proof either. The impact of having a JVM go down is proportional to
the number of sessions connected to it. While you may (or may not)
have lost the ongoing transactions for that JVM, the site is still up
and able to honor new requests without waiting for the JVM to come
back up. Indeed, if the requests are truly stateless the client never
knows that it is a different JVM.
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.
Caveat: I have no knowledge of their product so I don't know
exactly what they're doing. I'm only talking about general
reliability principles.
Regards,
Don Bate
At 7:31 AM +0000 2/9/01, John Harby wrote:
>Also, I would wonder if you are offering some IPC/shared memory
>space accesible by all the VMs, don't you have to modify the VM
>code itself to accomplish this? This sounds like a real high-maintenance
>high quality risk effort to me.
>
>>From: Jeff Schnitzer <[EMAIL PROTECTED]>
>>Reply-To: A mailing list for Enterprise JavaBeans development
>><[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Entity beans, clistering and scalability
>>Date: Thu, 8 Feb 2001 14:47:20 -0800
>>
>>>From: Bobby Woolf [mailto:[EMAIL PROTECTED]]
>>>
>>>GSJ has what we call Extreme Clustering, which can be thought of as VM
>>>pooling. It's like session bean pooling, where a client is given a bean
>>>that's available. When the client is finished, the bean is
>>>returned to the
>>> [...]
>>
>>Pardon my (perhaps) naivete, but why on earth would starting multiple
>>VMs on the same box increase scalability? It would seem like you're
>>just going to consume a lot of extra resources, when all you really
>>should need to do is start more threads.
>>
>>I can understand the advantage if your OS/JVM only supports green
>>threads, but then I would offer the suggestion that it's time to update
>>your JVM.
>>
>>Please tell me what I'm missing.
>>
--
Don Bate | Specializing in Consulting and Mentoring in
Bate Consulting, Inc | Object-Oriented Technologies,
| Software Architecture, and Software Process
(972) 618-0208 voice
(972) 618-0216 fax
[EMAIL PROTECTED]
===========================================================================
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".