Jboss clustering support in multitier application

[kenksy]

Hei,

I am soryy for my last email. Perhaps i asked questions that are answered in jboss documentation. I am working on one project that has native xml embedded db and webservices on presentation layer.


My question is if I use jboss to deploy webservices, probably wrapped with session beans. I asume that jboss does well support for clustering at session bean layer(webservices). How could I achieve clustering at xmldb level, though it provides replication api but without any support of communication and naming infrastructure.

Conceretly, is it possible to add my replication logic at jboss level which controls all clustering of xml db replicas through jboss's powerful communication and naming mechanism.

I hope i described my problem clear, in case if not I can post it again. :)


Thanks in advance.

Kensky

[brian.stansberry]

So you want to use JBoss clustering to replicate the xml around the cluster, and then update local copies of the DB when state changes?

Two vague options, both involving JBoss Cache:

1) Use JBossCache as a write-aside cache. I.e. if the app wants to read data, check the cache first; if found use it. If not, read from db and put in cache.

If app wants to write data, put in cache first then write to db.

Create an implementation of TreeCacheListener and register it with the cache. You will get notifications when nodes in the cache are changed. Ignore notifications that are caused by your own local activity (use a ThreadLocal to flag that the thread is doing local activity. Pay attention to notifications not due to local activity; these mean state was changed on another server. Read the updated state from the cache and write it to the local DB.

2) Use JBossCache as a write-through cache, with a CacheLoader targetting the DB. Your app only deals with the JBossCache instance. If data is not in the cache, the call goes through the cache loader to the DB to get the data and load it into the cache. If data is placed into the cache, it is also written to the DB. When data is replicated from another server, the new data is also written to the DB.


Advantage of #2 is it is simpler. But the existing CacheLoader implementations use a very primitive database schema to store the data. If you wanted complex mapping of data, or your database doesn't support JDBC you'd need your own CacheLoader implementation.

[kenksy]

Many thanks for reply.

Yes I have sleepycat berkeley db xml on the backend.
BDBXML provides only replication API but no communication and naming mechanism. Can I use jboss communication and mechanism to handle bdbxml data replication and transport.

Or do I need to write my own mechanism to handle this problem.

Thanks and Regards
Kensky

[brian.stansberry]

I'm sorry, I really don't know enough about BDBXML's replication API to give you a very good answer. Are you saying they expose an API that 1) on the origin server gives you access to data that needs to be replicated and 2) on the destination server(s) allows you to integrate it? But it's your responsibility to move the data around the network, determine who to send it to, etc?

If so, you could create an MBean service for this that utilizes JBoss' HAPartition service. HAPartition provides support for group RPC calls and a registry of the servers in the cluster that have your service running. Simplest way to write such a service is to subclass org.jboss.ha.jmx.HAServiceMBeanSupport.

There is some documentation in Chapter 9 of the Clustering Guide that explains a bit about the architecture behind this. Probably a good idea is to look at that and then look at the code for the HASessionState service as an example of such a service. The HASessionState code can be found in the "cluster" module of the JBoss AS codebase, particularly package org.jboss.ha.hasessionstate.server.