Re: [JBoss-user] clustering question

2002-04-30 Thread Andrew Scherpbier

I know this is OT, but the thread reminded me of this...
Has anyone looked at using something like "JSR-107: JCACHE - Java 
Temporary Caching API" to help in keeping cached entity beans in a 
cluster synchronized instead of relying solely on the database?

David Jencks wrote:

>I don't see a response yet from the experts...so I will jump in.
>
>Don't use commit option A with clustering, and do use whatever your
>database supplies for select for update.  The clustering implemention
>relies on database locking to synchronize the different copies of entities.
>
>I actually don't know of any other way to get consistency, but would be
>interested in finding out if there are other ways.
>
>david jencks
>



___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



RE: [JBoss-user] clustering question

2002-04-30 Thread Sacha Labourey


> I don't see a response yet from the experts...so I will jump in.

Sometimes, I sleep ;)
 
> Don't use commit option A with clustering, and do use whatever your
> database supplies for select for update.  The clustering implemention
> relies on database locking to synchronize the different copies of 
> entities.

exact. See specific case for read-only beans.

> I actually don't know of any other way to get consistency, but would be
> interested in finding out if there are other ways.

Distributed cache is one way, but you already knew that :)

Cheers,



Sacha


___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



RE: [JBoss-user] clustering question

2002-04-30 Thread Sacha Labourey

Hello Dennis,

For now, for entity beans, we use pessimistic locking at the database level i.e. we 
use the ~"SELECT ... FOR UPDATE" features of databases to lock database rows. 
Consequently, you need to run in commit option C (or B if you have a kid whose name 
starts with a B... it won't make a huge difference.)

Now, if you use commit option A, it means that you have read-only beans. In this case, 
it makes perfect sense.

Then, if you want caching + commit option C, then you will either have to:
1°) wait on a future release of JBoss that may have distributed cache (nothing 
planed)
2°) use one of JBoss' partners distributed cache (see the partner page on 
JBoss web site)

Anyway, read the clustering doco, you will understand all this very easily ;)

Cheers,


Sacha


> Let's say I cluster two jboss servers and I have an Entity Bean with
> commit option A.
> 
> Are the attributes of the Entity Bean clustered?  ie: user on server 1
> calls a set Method, then user on server 2 calls the get method for that
> attribute.  Can I expect the attribute to be current on server 2?
> 
> If the data wasn't clustered I would say no because server 2 would think
> it has exclusive access to the data (commit option A) so it wouldn't
> load it.  I want to know if the clustering broadcasts the attribute
> changes??
> 
> Thanks
> Dennis
> 
> 
> 


___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] clustering question

2002-04-29 Thread David Jencks

I don't see a response yet from the experts...so I will jump in.

Don't use commit option A with clustering, and do use whatever your
database supplies for select for update.  The clustering implemention
relies on database locking to synchronize the different copies of entities.

I actually don't know of any other way to get consistency, but would be
interested in finding out if there are other ways.

david jencks


On 2002.04.29 17:14:51 -0400 Dennis Muhlestein wrote:
> Let's say I cluster two jboss servers and I have an Entity Bean with
> commit option A.
> 
> Are the attributes of the Entity Bean clustered?  ie: user on server 1
> calls a set Method, then user on server 2 calls the get method for that
> attribute.  Can I expect the attribute to be current on server 2?
> 
> If the data wasn't clustered I would say no because server 2 would think
> it has exclusive access to the data (commit option A) so it wouldn't
> load it.  I want to know if the clustering broadcasts the attribute
> changes??
> 
> Thanks
> Dennis
> 
> 
> 

___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



[JBoss-user] clustering question

2002-04-29 Thread Dennis Muhlestein

Let's say I cluster two jboss servers and I have an Entity Bean with
commit option A.

Are the attributes of the Entity Bean clustered?  ie: user on server 1
calls a set Method, then user on server 2 calls the get method for that
attribute.  Can I expect the attribute to be current on server 2?

If the data wasn't clustered I would say no because server 2 would think
it has exclusive access to the data (commit option A) so it wouldn't
load it.  I want to know if the clustering broadcasts the attribute
changes??

Thanks
Dennis





signature.asc
Description: This is a digitally signed message part