Ganymede Release 2.0
September 17, 2008
THINGSTODO

---------------------------------------------

0) Scalability issues

Right now, the Ganymede server loads all data managed into memory.
This is reasonably efficient with a good generational garbage
collector, but it's possible that using a random access binary file
for the database, when combined with an in-memory cache system using
the Java weak references API could give better scalability.  Memory is
cheap these days, so the Ganymede design isn't too bad for our
purposes and size, but it might be good to experiment with the basic
engine to see whether things can be made more scalable, particularly
with the new, and highly efficient Ganymede 2.0 sync channel
mechanisms.

Of course, the client has some important scalability issues.  In
particular, there are places where the client will generate pop-up
choice lists with hundreds if not thousands of choices in them.  This
is not workable from a user interface perspective, and may be a real
burden on the client's memory.  For real scalability it might be
better to require the user to manually type in items when the lists
get too big.

Note, however, that during development of Ganymede 2.0, we test-loaded
the Ganymede server to 250,000 users and 250,000 groups of random
data, using the userKit.  At those crazy levels, the Ganymede server
balloons up to 600 megs of RAM, but it still works fine.

1) Documentation/Help

The Ganymede client includes support for a basic HTML help
system, but we don't have the HTML help web written.  Given our
resources and priorities, it isn't clear that we'll be able to do this
ourselves anytime soon, but it really should be done.

2) Two phase commit for client access

The Ganymede server internally uses a two-phase commit protocol
for handling its transactions, but it does not provide a two-phase
interface for clients that may be coordinating transaction commits for
an external system.  As a result, while Ganymede can be used to
master cross-database transaction commits using the DBEditObject
commitPhase1() and commitPhase2() methods, it doesn't support a client
attempting to verify transactional consistency without performing an
actual commit.

No one has asked about this yet, but at some point I may need to
expand the client API to allow some sort of 'verify ok to commit'
method call which, if it returns a successful result, will guarantee
that a later commit would proceed to completion successfully.  This
will involve a good bit of reworking of the server's internal commit
operations, and there may be issues of deadlock and timeouts to be
considered as well.  At present, transactions lock all portions of the
database involved in the transaction while the commit logic is being
processed, but if there might be an indefinite delay between phases 1
and 2 of an externally-accessible two phase protocol, we have to
either risk unlocking the server and then hoping we can re-lock the
server in a timely fashion later, or risk leaving those portions of
the server locked until such time as a phase 2 order arrives.

I'm not sure how folks handle this problem, generally.

3) Support server targeting with common client

Right now at ARL, we are running two instances of the Ganymede server,
one for our internal information, and one for accounts in the DMZ.  At
present, the Ganymede client and admin console are 'pre-loaded' with
properties specifying where the Ganymede server is.  It would be nice
to have a way to start the client or admin console, have the client
code get a list of local Ganymede servers, and present the user with a
choice of server to log into.

This may well not be worth the effort to code it, but it might be nice
to do.  Letting a single admin console monitor multiple Ganymede
servers might be particularly nice.

---

Jonathan Abbey, jonabbey@arlut.utexas.edu