Well, I *think* with Hibernate, JDO, or OJB I would have the same issues
regarding the agents. I would still need to figure out a way to have
them be able to do queries and database operations without having an
actual connection to the database. But maybe I'm wrong, I will check it
out. As far as EJB, we are currently not using J2EE and I'd like to keep
away from it.

>> Another idea: use Jini. They have concept of distributed

transactions,

>> very elegant concurrency control mechanism through leases.

Yup, our first implementation was using Jini. But I would still have to
solve the issue of centralizing the database connections in a single
process/host. I'm not so much looking for the agent infrastructure part
of the equation, more so how to keep agents from creating database
connections without a ton of RMI traffic. As always, thanks for your
input. I'll check out those other projects you mentioned.



________________________________

From: Roman Rokytskyy [mailto:rrokytskyy@...]
Sent: Wednesday, April 28, 2004 2:31 PM
To: Firebird-Java@yahoogroups.com
Subject: [Firebird-Java] Re: Looking for some design ideas

> 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



Yahoo! Groups Sponsor
ADVERTISEMENT
click here
<http://rd.yahoo.com/SIG=129hrq25p/M=281792.4727319.5879690.1261774/D=gr
oups/S=1705006764:HM/EXP=1083274259/A=2058224/R=0/SIG=116652qbq/*http://
my.yahoo.com/promo/ppets.html>

<http://us.adserver.yahoo.com/l?M=281792.4727319.5879690.1261774/D=group
s/S=:HM/A=2058224/rand=754796398>

________________________________

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/Firebird-Java/

* To unsubscribe from this group, send an email to:
Firebird-Java-unsubscribe@yahoogroups.com
<mailto:Firebird-Java-unsubscribe@yahoogroups.com?subject=Unsubscribe>

* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .