> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of James
> Cook
> Sent: Monday, July 23, 2001 7:55 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new wait(1000) not good
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> > fleury
>
> > Let's finish and stabilize the 2.* series. This will need to go
> > in the new
> > 3.* series where we can rethink locking and clustering. A
> > locking that will
> > support distribution and multiple instances will be interesting.
>
> If you mean synchronizing bean access in the container across multiple
> instances of the container, I would ask why? If I misinterpreted, I
> apologize.
>
Our app is a perfect example. We have one large database server and 3-4
smaller App servers each running Jetty/JBoss. We need to synchronize some
entity beans across JBoss instances so we use "select...for update". I
firmly believe though that the datastore should be doing all the
synchronization in a clustered environment.
> I currently know of *no* EJB container that can synch EJB instances across
> distributed containers. Gemstone (brokat now) may be able to, but only
> because they have a persistent cache architecture which is really a
> distributed database, and it is external to their container anyways. The
> other guys (and you guys) may be able to do it by throwing enough
> resources
> at it, but it would still be very difficult.
>
> In the end, I scratch my head and wonder why? I can't even think of a good
> reason to synch access to beans in a *single* container. No one
> really does
Read about commit option A. I think synching access in the container for
'A' is a perfectly viable solution. Although, using something like
"select...for update" would make the current JBoss code base much more
simple. The question is, does something like "select...for update" exist
for all DBs? probably not.
> it anymore besides jBoss. It has been proven to be contrary to performance
> and can be prone to deadlock issues.
>
I agree, but synching is perfectly viable for commit option A. Option B and
C is another story.
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
