EntityBean updates

[parressh]

Does JBoss support EntityBean synchronization in a clustered environment so that when an entity bean is modified on one node, the other node is notified of the update? If so, does this work with CMR? If not, do any appservers support that or are there any plans to add this, or would I have to come up with my own synchronization code?

Thanks in advance.

[belaban]

Currently EntityBean handling in a clustered environment requires a shared database. Access to EntityBeans acquires a lock (transaction) on the DB (this is commit option B or C), so serialized access is guaranteed.

Changes made to an EntityBean EB1 by one node are therefore also visible by all other nodes.

In the future, we will use the Cache/JBoss to replicate changes. In the case of nodes having their own local database, this will apply the change to each local DB.

Have a look at the Cache/JBoss forum to get updated about the latest info.

Bela

[softtob]

Hi,

I think it is the wrong way having a shared database to manage clustering with Entity Beans. What if the computer crashes that has the shared database.

I have the problem right now that I need clustering with entity beans and I do not want to use replication between the databases on the computers becuase I belive this can be handled by the app server.

Does anyone know the project time lines for the Cashe project?

Anyone know a really good application server that can handle this?

Thanks,
Softis

[belaban]

> I think it is the wrong way having a shared database
> to manage clustering with Entity Beans. What if the
> computer crashes that has the shared database.


I agree. But it is frequently used, because many people believe the DB is very safe and won't ever crash...


> I have the problem right now that I need clustering
> with entity beans and I do not want to use
> replication between the databases on the computers
> becuase I belive this can be handled by the app
> server.


This is exactly what the Cache on JBoss will provide. Replication will essentially be between caches (in-memory), writes will be replicated and persisted in the local database. So we degrade the database to a dumb object store essentially. No database replication needed.

Note that the Cache will provide both for shared-database and local-database scenarios.


> Does anyone know the project time lines for the Cashe
> project?

We're moving aggressively on this: I believe JavaOne 2003 is the target we're shooting for (June).

Bela

[softtob]

In my scenario right now I have a server where an app server is running against a local database. Here is a administration site deployed.

Then I have several clients on the LAN that also has an app server and a local database. The clients needs information from the server. The clients uses the information from the server and add new data thru a local administration site.

You might wonder why I use such complex solution but the customer that wants this is a fabric that wants to log the uptime, downtime, errors, etc on the machines, and if the server is down or the network cable gets broken the machine shouldn't stop for this. That is why I want clustering on all computers. The customer also wants to use all free software so guess what software I'm using ;-) JBoss, MySql and Linux :-) I tested both way replication on MySql but there was a bug (of course) that couldn't replicate correctly. Instead of me writing my own replication, maybe you can suggest a third party (free) replication solution.

I read some other threads and you said you will have a test cashe by the end of this week. Are you still up to that? Does it fit my needs?

I'm really preciate any help from you and think the JBoss server is the greatest free one for us developers.

BTW: Found that weblogic supports clustering of EJBs if anyone intrestead...

SoftIs

[slaboure]

> SoftIs WROTE:
> BTW: Found that weblogic supports clustering of EJBs
> if anyone intrestead...

Sure they do, but they don't have a distributed cache as well. Consequently, as far as entity beans are concerned they do not have a feature that we don't have => you will have the same "problem"/situation with Weblogic as with JBoss.

Cheers,


sacha

[belaban]

> I read some other threads and you said you will have
> a test cashe by the end of this week. Are you still
> up to that? Does it fit my needs?

I lied :-)

But seriously, that was my intention. However I got side-tracked by by hardware issues.

What I will have pretty soon is a cache which let's you replicate its entries between nodes.

However, we already have a simple replicated cache which is part of JavaGroups and supports JDBC to persist its entries: have a look at org.javagroups.blocks.DistributedHashtable. It has far less functionality, but maybe it already does what you want.

Bela

[jmntn2000]

Why not use a database that supports clustering itself. I think postgresql released something for this? this would still appear as one database to jboss.

[belaban]

> Why not use a database that supports clustering
> itself. I think postgresql released something for
> this? this would still appear as one database to
> jboss.


Yes, there are several DBs that provide replication at the DB level.

This may be a valid solution, but be aware that

- Most DB replication schemes use asynchronous replication. This means that the update is put onto a queue, which is periodically flushed to the backup database. This means that if somebody is updating the *same* data in different nodes, they will overwrite each other's updates, and may lead to inconsistencies. Sometimes this is not a problem, e.g. when an app only uses one node, and the other node only serves as a backup

- The cache would still be useful: all reads on an unlocked bean would *not* have to go to the DB.


But, you're right: database replication is another tool that may be the right choice for some application. It really depends on the app requirements.

Bela