A common observation goes like this ...

If I execute several setXXX() methods against an entity bean as a group, I get some rather intense database activity. I was wondering if something could be done to reduce the number of SQL UPDATE calls (and perhaps their associated ejbLoads) to 1 total, as opposed to 1 per setXXX().

It is a very bad idea to make individual set or get calls on an entity bean within its own transaction. You really want to bundle a bunch of accesses to one or more entity beans into a single transaction, thereby reducing the number of database accesses.

The "right" way to do this is to never access your entity beans directly from your client, but always to access them though a session bean. Basically, you want to use a session bean which says "get me a bunch of information", and then this session bean can do all the getting and setting on the entity beans.

Why this design pattern? Because then you can specify "Required" as the transaction attribute on the session bean and all the entity bean accesses will run in the session bean's transaction. Since each entity bean will be loaded only once per transaction (or not at all, if using caching) this will have a huge impact on your overall performance by drastically reducing your database access.

Another approach is to use client-demarcated transactions. Here, you start a transaction on the client, access all the beans you want, and then commit the transaction. Again, since each bean is loaded and stored at most only once per transaction, this will have the same effect. However, generally, client-demarcated transactions are frowned upon because it is much harder to control a client than to control the container.

One may suggest making the updates asynchronous, which is a very bad idea, because the whole idea of transactions is that you know it worked (that is, committed) or you know it failed (that is, rolled back). Saying "we'll try to do it, maybe later, don't worry about the results" breaks the whole model!

Of course, if you are in a hurry, you could always spawn off a client thread which does the client- demarcated transaction commit asynchronously and then come back to poll the results later.