JBossDeveloper

Just wanted to give an alternate view of EJBs. I’ve developed a multi-transactional web application (an online community) using J2EE, EJBs, & JBoss and I’m quite happy with the technology and the performance. The performance numbers and architecture are posted in the message ‘Informal Performance Numbers For JBoss 3.0/Jetty’. When one person can develop a mutli-transactional web application that is capable of handling 60 to 100 simultaneous users on an entry level server, I would say the technology to develop that application has a lot of practical use to many business applications.
The biggest advantage I get from using EJBs is the ability to handle multiple transactions. Getting a software system to handle multiple transactions reliably is no small feat. I’ve witnessed knowledgeable and competent teams of software engineers unable to successfully accomplish this task in a reasonable time frame for client server applications.
I run my web app on Linux with JBoss but I’ve also tested it on Windows 2000 with Weblogic. I had very good portability between the two platforms. I haven’t tested with WebSphere however.

As far as peformance of EJB goes, the spec is still evolving. Once they work out the problems, and the spec stops changing, various container providers will probably be able to spend more time on optimizing peformance. It seems like the switch from 1.1. to 2.0 was a major change for the vendors, and as a result probably a lot of sloppy poor peforming code was written to get a release out the door that accomodated the new spec.

It seems like the Relational databases have continued to get faster with each release. I wasn't programming back when they first came out, but I wouldn't be surprised if they were considered slow when they first came out.


Either vendors will deliver on the promises of EJB ease of development and performance in the next few years or people will walk away. I think once the spec stops changing performance will improve and tools to ease development will appear.

ThorntonD, it so happens that at my previous job, our main customer was a dot-com. Burned through money like with a flamethrower, but had some serious web usage.

60 to 100 simultaneous users? Oh, gee, that's a spit in the bucket. I can think of home sites who get more hits than that. Without EJB, you should be able to support that on a 386 SX. I'm not exaggerating.

In early 2000 their data entry site alone had a few hundred simultaneous users. And it had to support not only the actual entry and listing, but also do heavy duty statistics and filtering on several millions of records for the managers. In fact, on a cartesian product between tables with millions of records. You know what it ran on? On an ancient PC running Linux. And with a Sun Ultra 5 for the Oracle database. Except about 5 minutes once every few hours, when the statistics cache was refreshed, the CPU utilization stayed well under half, memory usage was in the tens of megabytes only, and response was instant.

It also supported a home-brewn clustering (with the session being shared between the servers), though that was never really needed to get good performance. It also had a far more sophisticated scheme of permissions than the lame "let's make something that sounds great for clueless bosses" declarative model of J2EE. And a few other things.

And yes, that site was developped by a single person: yours truly.

Which is another thing I'm not convinced about EJB. I keep hearing about how one person can do mountains of work in no time with this miracle technology, but my practice says completely otherwise. It says it's marketing BS. As soon as you have to do something more than a simple low-traffic page, it's actually _more_ work than just going plain Servlet/JSP.

For example think of the biggest BS of them all: the Entity beans. Ok, let's take the fast lane with SQL around it when you need to access more than one record at a time. So you end up needing to know _two_ API's instead of one: entity beans _and_ SQL. Why couldn't I just stick to SQL in the first place? Let's also cut down on remote calls, and wrap the data in one big data object after it's been read by the entity. Or worse: let's wrap everything in a session facade, which in turn wraps the data in a data object. So I ended up writing two data object classes _and_ a wrapper facade, where one data object should have been enough. (The entity bean _is_ already a data object.) Etc.

Did it really save me any work? No. It actually created more work. Including more maintenance work across all those extra classes which duplicate functionality.

well there you go. You are 3733+ h@X0r

LOL. Well, nah, I'm just your average John Doe who's not affraid to use a cache or a connection pool. I mean, hey, caches are described in hundreds of books, and you can also find an existing good implementation on the net if you do a search. Maybe 20 years ago they counted as l33t hax0ring, but not nowadays.

It's also that Java is actually pretty fast, and more than fast enough for a typical web application. These things don't do intensive scientiffic calculus. (Or at least I never found a site which was computing thousands of matrix operations for each page.) If a web site gets stuffed, it'll typically be waiting for the database not for the servlet. Hence, some minimal optimizing the database access will do you far more good than some BS which has "Enterprise Edition" in its name.

the point is all techs have their up's and down's. The best technology is always the one that solves the problem you have today. EE stuff does it for me, maybe the next guy one along will be good for you.

I completely agree with ThorntonD's assesment. The primary benefit of EJB's is the ability to seamlessly compose complex transactions.

If you don't have these sorts of transactional requirements in your application, then I agree with the earlier comments about EJB being very wasteful.

There are also situations where entity beans can give you huge performance advantages. Yes, you heard me correctly. When you have a small enough number of objects (i.e. all the ones you use fit into memory), and you need to manage concurrent write access to the same instances of the objects, and you can use only local interfaces, entity beans give you a very fast transactional cache (don't forget to use NoPassivationCachePolicy!). If you don't have this situation, don't use entity beans.

When you use entity beans this way, you do not encounter the famous "n+1" finder performance problem. Your finder calls require one database access, not n+1. If you don't believe me, browse the JBoss implementation of the EntityBeanCache.

EJB's are not the right answer to all problems, but they are definitely the right answer to some.

Corby

Well, I'll give you that. _If_ you really need some horribly complex transactions that span across more than one server and/or more than one database, I guess you can save some time by letting the EJB container do that for you. However, I'd guess most actual projects don't fall in that category. For all the actual projects I've been in -- and I'm talking enterprise and/or dot-com scale projects -- you only need to set auto-commit to false in the beginning, and commit at the end or rollback in the catch block, to get all the transaction support you'll ever need. It's standard JDBC too.

The thing with the entity beans... well, that's a rather artifficial case, isn't it? Yes, if you have only about 200 objects which never change and are only read once and are used intensively ever after, JBoss's entity cache will do just fine. But then again, in the exact same case using a plain old HashMap achieves the same thing, is even faster, and takes only a couple of lines of code. (A few more lines will also get you time-out functionality for that cache, if you need that. Or you can download an existing timed cache off the net.)

Basically what I'm saying is that if you compare a well written EJB application to a very poorly written non-EJB one (in this case, lacking its own caching), and even then on a totally artifficial case, well, I can see how EJB would win. But that really is just as rigged a comparison as Microsoft's Pet Store .NET benchmark.

How many real projects did you have where _all_ the data fits in the cache? So you end up with two API's instead of one (entities and SQL), duplicate functionality between them, a lot of pointless extra classes to keep in sync, and so on. You'll also end up with situations where mindless copy-and-paste or just bad reflexes produced a disaster. (E.g., where someone thought "hey, cool, JBoss has a cache" and applied the same code to a 1 million record table. It worked in testing with the 100 record test database, but on the client's computer it grinds to a halt.) Etc.

Basically: do you really think that the kind of person who couldn't use a HashMap nor figure out how to turn auto-commit off on a connection (and thus benefitted from EJB), is capable to deal with the above problems when they hit?

Moraelin,

The project I am working on qualifies as a 'real' project. I am implementing a large, complex enterprise software system at a Fortune 20 company. I make heavy use of EJB's, and limited use of entity beans, and not for the sake of using them. I use them specifically because of the reasons I outlined above.

Your points are somewhat overstated. Specifically:

1) There are many situations where you benefit from EJB transactional semantics. You pointed out an excellent example where you are working with more than one database back-end. In my case, I work with message queues. Enlisting JMS resources and JDBC resources within the same transaction can lead to tricky semantics without the use of the EJB containers. I think there are many 'actual projects' which also use both JMS and JDBC resources. Whether these are 'horribly complex' situations is a subjective matter.

2) HashMaps can NOT do the same thing as entity beans. Try running two concurrent processes. Both processes modify the same object. One of the processes rolls back the transactional at the end, with the intention of restoring the object to its state at the beginning of the transaction. Try doing all that, and preserve ACID properties, with a HashMap.

3) A server with 1 Gig of memory can usually hold more than 200 instances of a object. Several of my entity beans have hundreds of thousands of instances.

I use a HashMap to implement my object cache whenever possible. When I need the EntityBean container to implement my cache, then I use that. You imply that using 'two API's instead of one' to implement caches is overly complex. If you properly encapusulate acccess to your factories, it is actually incredibly simple.

Corby

Looking at the Java-oriented message boards, I am finding it extremely common for people to confuse:

EJB's are not the right choice for my project.

with

EJB's are not the right choice for all projects.

Actually, there is a very simple way to get a transactional HashMap. Without even needing to extend the HashMap itself, even. You just need to move the cache updating after the con.commit() in the try/catch block. If the SQL bombed and you take the rollback branch (i.e., the catch block), the cache update was never done in the first place, so it's as good as rolled back. If the SQL went through, the cache gets updated, and everyone is happy.

As for two processing accessing that at the same time, well, that's why the "synchronized" keyword works on data objects too :)

JMS are an asynchronous and potentially slow thing. I wouldn't encapsulate them in a regular transaction. Think of how your bank handles money transfers. Let's say I send you 20 bucks. Basically if it failed on your bank's end (e.g., I typed a digit in the bank account wrong), my bank gets a message back to rollback the operation. Basically I'd do the same thing. Use the JMS part for the transport only. You don't roll back messages and pretend they never happened, you just use them to transport the information for the rest of the transaction. E.g., that the process bombed at one end and needs to be rolled back from history at the other end too.

(But it should be noted that I don't know exactly what you're doing with those messages there. It may well be that you actually need to rollback a message the hard way. Just because I can't think why and when that may be needed, doesn't mean it can't happen.)

1) If you aren't updating data in the HashMap until the transaction is committed, then you are incurring the overhead of cloning each and every object instance that you access so that you can get a non-cache instance. Now you're starting to see where these performance penalties come from...

Using the synchronized keyword is fine for method-level safety, but it does not preserve the integrity of concurrent transactions.

And you still haven't achieved a good level of functionality that comes from the pluggable caching and locking policies, the ability to define optimistic or pessimistic transaction scopes, CMP if you're into that sort of thing, etc.

You haven't run across a use case that requires you to use Entity Beans, and that's cool. But when you are lacking that practical experience, it is very misleading for you to explain that you can duplicate an Entity Bean container with a HashMap and a few lines of code.

2) When you enlist JMS as a transactional resource, you do not retrieve delivered messages on a transaction rollback. Rather, the messages are not actually delivered until the transaction is committed. The use cases for this are as varied as those for enlisting JDBC resources in a transaction.

Even assuming that all your points were true, I still fail to see why should I put up with the _massive_ overhead of the EJB architecture just for that. Basically while ok, I'm not opposed to having code already written and debugged by someone else for transactions and caches, the whole rest of the EJB abstraction is unneeded, inefficient and wasteful.

But even of some of those points, I'm still not convinced.

- Cloning data objects... as opposed to what? As opposed to the gazillion of stubs, proxies, interceptors, principals, contexts, and other crap used by an application server whether I need them or not? And you usually end up cloning data with EJB's anyway, if you want to get it from the Entity Bean to the client, since you don't want a remote call for each field in a 20 field record. Just for my newbie curiosity: exactly how is my cloning data objects any worse?

- Sending messages only if the transaction succeeds... well, that's the same issue of putting stuff after con.commit() in the try-catch block, isn't it? There you go. A message that is sent only if the database stuff succeeded.

- The "synchronized" keyword... it's only as good or bad as you use it. Yes, only method level synchronization is often not enough, and the original Vector and Enumeration with all methods synchronized are a prime example of that. And they're no 1-to-1 substitute for transactions.

You can, however, also synchronize on any arbitrary object. You can also use it for other wonderful stuff, like setting a "this record is locked" flag on whatever object you wish. Basically, yes, you'll need to be a bit more creative than just declaring every single method as synchronized.

- Optimistic locking... wow, you mean EJB's save me all the effort of setting and checking a timestamp field? To think of all the minutes I could have saved in writing database programs if I had EJB's ;)

And so on and so forth. All those problems have decade old solutions, well documented in a thousand books and on a thousand web pages. In most cases you don't even have to actually copy and paste that code from a web page, because you can download an already compiled package.

But again, if an application server simply came with those as libraries, I wouldn't say no. Sure, I might as well use their cache, instead of writing mine. Sure, I might as well use their transaction support, instead of keeping track of them myself. Sure, I might as well use their optimistic locking, instead of having my own timestamp on those records. (Hey, it saves me a whole " and my_timestamp=?" in the SQL update.)

No problem with that. Using existing libraries is good. No arguments there.

What I _do_ have a problem with is the whole inefficient EJB architecture that I need to use to get that functionality. Do I really need to discover my own classes through JNDI? I mean really, I already know what class to call, because I wrote it myself. For that matter, do I really have to go through a proxy object or stub for calling my own classes? Do I really need to write half a dozen classes for each actual business class? Etc.