> So, I want to create a central server and have that be the only
> process that actually uses JDBC connections. What would be the most
> expedient way to modify my agents so that they don't use JDBC directly
> but go to the server instead? There are a few different options.
> Modifying my Persistence Layer to be used as a set of RMI interfaces
> -- i.e. a Database RMI Server or to create specific RMI services that
> encapsulate the database but provide application level semantics.
> There's also the problem of transactions. So I would probably need a
> Remote (or Serializable) transaction that encapsulates a connection on
> the server side.

Are there any reasons not to use some existing persistence layer (EJB
with CMP, JDO, Hibernate, OJB, etc.) and let it care about the
database? Transactions are in this case, in theory though, relatively
easy problem - all such layers support transactions, you have only to
use it correctly. Check JTA specification, it is relatively easy to
support and you get a number of distributed tx manager implementations.

Another idea: use Jini. They have concept of distributed transactions,
very elegant concurrency control mechanism through leases. You can
provide a number of persistence resources, you can use JavaSpaces to
coordinate your agents and even persist your state there. Probably
this would be the most appropriate solution, since Jini was designed
for multi-agent systems. Also have a look on E-Speak from HP and Ninja
project from Berkley, they are different, but might give you nice ideas.

Roman