Many Beans, One Table

[cwstanton]

We have made the mistake of building all our applications in a single ear. It is a mistake because the company doesn't sell them that way, and it's a nightmare to keep up with versioning.

The core problem with splitting out the applications is in the "shared" ejb's, like "User." Every application reuses the "User" bean. In this way, company's can buy as many of our apps as desired and maintain just one user table.

It is my understanding that if we leave "shared" ejb's in one jar, and put app-specific ejb's in a separate jar, we cannot use CMR between the two. (CMR can only exist within a single deployment unit, yes?)

Which lead me to the thought that I could use a unique bean per app and just map it to the same table. "App1User", "App2User", etc, all pointing to the user table. However, it strikes me that this will present concurrency issues as the CMR container won't treat them as being the same "table."

Are any of my assumptions about deployment units or concurrency wrong? How are others solving this sort of problem in the real world?

Thanks!

Respectfully,
Charles

[benwalstrum]

I'm not 100% sure on having relationships outside of a single JAR, but it definitely sounds right to me that they wouldn't work that way.

One solution to think about is using Xdoclet. It's very easy to use once you set it up. The nice thing is that you could create separate Ant tasks for each of your applications and you simply tell XDoclet to build only the EJBs that you want for that particular application. Since XDoclet creates all the deployment descriptors and such, you won't have to worry about maintaining n descriptors. This is essentially a one-time setup that will allow you to do multiple applications off of one codebase.

Regards,

Ben

[cwstanton]

Thank you for the suggestions.

We do use XDoclet extensively, and it does make building projects easier. However, it doesn't eliminate the underlying technical challenge.

Let's say we have two web applications, A and B. We sell app A to a company and they set up all their users. Then they decide they want to use app B. Naturally, they want to use the same users they have already defined. Here is our challenge....

If we bundle A and B into the same deployment unit, no worries. But we have so many apps, the .ear has become unwieldy.

If we bundle A and B into the same deployment unit for just this company, we have a CM nightmare on a scale of N apps times O customers.

If we keeps the apps as separate deployment units, then the User bean for app A will be in a different cache than the User bean for app B and therefore will present database concurrency issues.

Please correct me if I misunderstand this.

Thanks,
Charles

[benwalstrum]

You are right, there are some deficiencies with my proposal. I believe that it could be done, provided that there was a low number of applications (say 5 or so) without too much difficulty. But even then, there would be some issues.

For instance, if you want to create a relationship that is only used by one of the applications that would cause deployment issues for the application that did not have the needed EntityBean to complete the relationship.

The problem actually is bigger because you have a general versioning problem with your database. If Application A needs a new column on a table that Application B needs to use as well, a dependency has been made. How much of a problem this is will depend on how frequently you need to add updates to shared tables, and how many shared tables there are.

My recommendation would be that you break apart the applications into separate EARs that have relationships within their own projects. That is, each project would have its own Entity Bean jar that would contain a mapping to the same table as another application. I believe this is what you were talking about. This could be achieved even with giving the two instances of the bean the same class name but different JNDI names (in jboss.xml) - such as "app1/User" and "app2/User". I think that this will allow for the biggest separation and most flexibility, with the drawback being that a code update to one table could mean updating two EJB classes.

As for concurrency, I can't say 100% for sure that you would never have some sort of a dirty read in this situation, but JBoss does have options for transaction isolation, which you may want to look into (I'm not an expert). However, it is also important to remember that JBoss also has to work in situations where it is not the only application talking to a database. At the company I work for we have a completely different (non-Java) application that is concurrently updating the database. If JBoss can keep that concurrency problem in check, then it certainly can keep concurrency for two EJBs deployed in itself in check. Again, I'm not an expert on HOW it does it - I just know that it must have a method or else it would be completely worthless.

I'm sorry that I can't give you 100% conclusive information on your concurrency problem, but hopefully I have been able to point you in the right direction.

Regards,

Ben

[aparaapara]

Sure, packaging 2 apps into two different .ear files and accessing the same table present concurency problems, but no different than setting up a cluster of application servers running the same app. Unless you never plan to cluster your deployment...

The database and optimistic/pesimistic locking is designed to overcome this issue.

I see no problems with packaging UserEJB into every app.