1) lock db directory for user (using symlinks -- atomic nfs op) ... would be 
done external to derby.
2) open database for the user
3) do operation to satisfy caller's request
4) close db then remove lock.

This seems like kind of a funny architecture. Have you investigated
using Derby's existing client/server support? You could have an
architecture that was more like:
 - each of your N mid-tier apps is a Derby client
 - all connecting to a single Derby server which accesses the
   database stored on the NFS filesystem.

You'd still have the benefit that each mid-tier app could handle
any user request, but you'd avoid the expense of having to open
and close Derby on each request.

thanks,

bryan

Reply via email to