Discussions

The final version of JBoss 3.0, the Open Source J2EE server has been released. JBoss 3.0 supports J2EE v1.3 (EJB 2.0, Servlets 2.3, JCA, etc). The 3.0 is major release, with a micro-kernel architecture (allows network bootup from a tiny bootstrap), support for clustering of EJB's, cluster-wide hot deployment of EJB's, etc.

You can download the free "Getting Started" guide for JBoss 3.0 here. As the title suggests, this should help you get started with JBoss 3.0. Among other things it contains basic information on how to enable clustering.

You can buy the JBoss books (including a Clustering book that I must say is quite good) from Flashline here.

JBoss 3.0 introduces clustering features built on top of the JavaGroups (http://www.javagroups.com) distributed framework. With its fail-over, load-balancing, and distributed deployment features, JBoss Clustering provides the means to develop large, scalable, reliable J2EE applications within a free open-source code base.

The following features are available in JBoss Clustering:

* Automatic discovery. Nodes in a cluster find each other with no additional configuration.

All and all, for the 1st clustering release, we (Sacha Labourey and I) wanted to do basic clustering and to do it well. We wanted to avoid too much feature bloat and to focus on what we thought were the core, can't-live-without features of a clustered J2EE container.

Here's where this article comes in. We're looking for feedback on what features are important in a clustering environment so we know what to work on for JBoss forthcoming releases. Here's some things we're thinking about:

* We currently do not do any distributed locking or caching for entity beans. We're relying on the database for synchronization so we require Commit Option 'B' or 'C' and <row-locking> if you're using clustered CMP beans. OR we recommend you use third-party distributed caches like GemStone (which is a JBossGroup partner BTW). My experiences at Mercantec with a "clustered" farm of JBoss servers led me to believe that this was OK for the first release of JBoss Clustering. (see my article http://www.onjava.com/pub/a/onjava/2001/09/18/jboss.html).

So our question to you is, is it worth implementing? Do other vendors do it well? Does a distributed cache actually helps you? Or does it just cause you headaches? How do other vendors implement this?

* The "Nuke" pattern. With JBoss client interceptors, we're thinking of a pluggable fail-over policy for Stateful Session beans. With this pattern the SFSB state would live on the client. So, even if the entire cluster is "nuked", the SFSB client can still failover eventually.

* Subpartitioning. The ability to break up your cluster into higher performing units.

Well, that's about it for now. The JBoss QuickStart guide is a good place to get started if you want to try out JBossClustering. Or you can buy our for-pay clustering docs if you want more information. (Sorry for the solicitation.)

Weblogic does some interesting stuff with entity caches. What I'd like to see in an entity cache is the ability for the same bean deployed N times with different settings to be backed by the same cache instance. For example, Weblogic supports a read-only entity bean, however for me to keep the cache for these beans in-sync with a simultaneous READ-WRITE deployment of the same bean I have to programatically contact the READ-ONLY's home and caste it to a weblogic cacheing home interface, and call an appropriate invalidate method (which then sends a multi-cast invalidate) everytime a READ-WRITE bean commits a state change. If both deployments of the same bean were backed by the same distributed cache instance... this could occur seamlessly and prevent a subsequent ejbLoad on the READ-ONLY. (This scenario assumes the container is the only thing updating the persistant store).

Tyler Jewell has an excellent article posted on oreilly's site:
"Unlocking The True Power Of Entity EJBs"

One potential downside to this idea (I haven't thought it through completely) is how to implement container managed relationships efficiently when there are multiple deployments of the same bean. I mean if beans A and B are in a relationship where B is deployed multiple times (say READ-ONLY and READ-WRITE), which bean do I refer to in my relationship from A's vantage point? Right now I think I'd have to configure a relationship from A to both B(READ-ONLY) and B(READ-WRITE).

I have a setup with two web/app server machines which each talk to a single database machine. Each web/app server is running apache/tomcat/jboss. The DB is postgresql. A load balancer decides which of the two app server gets assigned the next session.

I have an entity bean (Participant) which has a cache size set at 50. It is a read write bean used for managing customer data for our clients. Client A goes to web/app server X and client B goes to web/app server Y and accesses a participant P.

So the solutions as I see it are:
1) The distributed cache forces a lock across all app servers in the cluster (Participant with primarykey 1 is locked) Thus when B attempts to get access to the bean, It will be locked until A is done with it.

2)When Bean B attempts to persist its value to the DB as part of the transaction, it gets a SQL error and the transaction rolls back.

I have noticed that if a bean has a cached value and I change the value in the DB directly, when the app server shuts down, the value in the DB gets reset to the cached value.

As I see it, the only option under Jboss 2 series then is to turn off caching for Enitity Beans.

Adam Young said:
"2)When Bean B attempts to persist its value to the DB as part of the transaction, it gets a SQL error and the transaction rolls back."

WLS can automatically do this with its optimistic locking strategy, and you can even (with 7.0) tell it to cache values across transactions, so it won't do an ejbLoad every time a new transaction starts up using the same entity. In this case, when the first client commits the transaction, it will multicast a message to all of the servers in the cluster to invalidate the entity in all of the caches so that they will reload on the next transaction. I'm not sure exactly what happens to the second client if it is in a transaction when that cache invalidation message comes in, but I assume it would roll back the transaction.

FrontierSuite also provides distributed caching for entity bean clustering. When an entity bean is modified by a client and the transaction complets, the changes are braodcast to the interested nodes in the clustered environment for notifications, so that, if the interested nodes are having the same object cached then they can invalidate the object. But if any client in the interested node is already in the process of using the same object when getting the notification, the client will be allowed to continue, but when the transaction completes it will rollback since it was a stale copy with which the client has worked.

BTW ObjectFrontier is a partner of JBOSS and FrontierSuite can enhance JBOSS to provide entity bean clustering capabilities.

Markus Blumrich Said:
"... however for me to keep the cache for these beans in-sync with a simultaneous READ-WRITE deployment of the same bean I have to programatically contact the READ-ONLY's home and caste it to a weblogic cacheing home interface, and call an appropriate invalidate method (which then sends a multi-cast invalidate) everytime a READ-WRITE bean commits a state change."

WLS has the ability for you to define, in the deployment descriptor, an invalidation target for a Read-Write bean to automatically invalidate in the cache the Read-Only version of the bean. You shouldn't have to programmatically do this.

Currently, Weblogic 7 is the only appserver that provides this functionality, unless you want to buy separate persistence management products like Object Frontier, Cocobase or Toplink, which will integrate with any servers.

7.0 cache-between-transactions is not exactly transactional caching - if I understand correctly how it works it simply reduces the likehood of optimistic rollbacks. AFAIK Persistence and Gemstone used to sell EJB containers with transactional distributed caching support.

Of course now you can use Coherence JCA .rar for transactional caching ;-)

>transactional caching - if I understand correctly how it
>works it simply reduces the likehood of optimistic
>rollbacks
v7.0 implements a distributed cache with optimistic (not pessimistic) app tier locking: you cannot set
cache-between-transactions to "true" in a WebLogic Server cluster when using exclusive concurrency.
However, you can set this element to true when using either optimistic or readonly concurrency.” See
http://e-docs.bea.com/wls/docs70/ejb/EJB_environment.html#1157072.

I tried to find some information about how to integrate JBoss and Orion in the same VM, but the only info I found was pertaining to Resin 2.0.5 and JBoss 2.4.4 (the link is http://www.practicalprogramming.com/plugin.html). Is anyone looking at, or has anyone successfully configured it, so that Resin and Jboss are running in the same VM? We're currently using Orion, but are interested in looking at Jboss because there are some bugs that aren't fixed (supposedly they're fixed in 1.6 but the people in the know have been talking about it for about 2 months now, but it still hasn't been released).

sigh.... orion is my favorite appserver for development, but there has been no activity for a loong time... i wonder what they're up to? i have almost given up on them, which is why im downloading jboss right now :-)

Orion essentially become part of Oracle 9iAS. Oracle licensed the code for their container. I understand the Orion developers are working for Oracle to get the J2EE 1.3 compliance (EJB 2.0 et al) completed.

JBoss has never been really good at keeping their site up to date. Also, I believe they are in the process of upgrading servers, and the application that runs the site. They are running into issues with both (like the Jive forum is not yet back online.) I think they have some other issues they feel are more pressing. This is not an excuse for them, as I said, they have never been good at keeping the site fresh. The current migration issues just make matters worse.

-Pete
--
How come the jboss.org site still claims it is in "release candidate" status?

<quote>
JBoss 3.0.0 is our current Release Candidate, stable version. It will run on 1.3+ JVMs.
</quote>

I understand that Tomcat server is inbuilt with JBoss3.0 Stable version. Can anyone tell me how to run a web application in it? I am using war file deployed in to server\default\depoy directory. I am using Struts framework also. It displays its first page and after clicking any link it says... context not defined. Even if I try to load the home page of Tomcat using http://localhost:8080/ it says the same thing "contect not define".. Can anyone tell/ guide me how to start/deploy my web application using JBoss???

Im new to EJB, JBoss 3, but not to Tomcat 4. We develop JSP based Web applications and deploy in Tomcat and now started testing JSTL and JWSDP 1.0 for our next project. But, we are trying JBoss also to start EJB. But, we dont know where to deploy WAR files. If we try http://localhost:8080/examples/ it says error. Where to start EJB. I came to know that CMP is the best one to use for Database related web applications.

Is there any document for JBoss 3 and few small samples for CMP to access DB and calling it from JSP/JSTL.

Will there be any performance improvement between, JSP/DB vs. JSP/EJB/DB based applications.

The JBoss 3.0 final release doesn't come with the webtest.ear file in the /server/default/deploy directory. If you have JBoss 3.0 RC1/RC2/RC3, you will find the webtest.ear file in the above directory. What you have to do is copy the webtest.ear file from RC1/RC2/RC3 to your new /server/default/deploy directory. JBoss will automatic deploy the examples for you. And you can point your web browser to http://localhost:8080/index.html

Ive developed one example given in Oracle site using JDev 9i and placed in deploy folder of JBoss 2.4.4, it worked for me from the test client which JDev creates, but when i deploy it in JBoss 3 (D:\JBoss3\server\default\deploy) deploy directory (Is this the right directory to deploy in JBoss 3), it says context not defined.

Please tell us how to start where to start. If there is any doc. for JBoss 3, pl. point us there.

Hi Sankar,
This is not an answer but a request.
I would like to have some readables on EJB.
Our company uses RMI currently and we would like to implement EJB so I would like to have the basic documents and understanding of EJB architechture if you have it send it to santosh@vaids-india.com
Thanks
Santosh

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.