Hi Bryan, Yup, that is another alternative except our traffic is probably too high for a single derby server so we'd need to shard. The downside of sharded derby (or other databases) is the hard routing between user X and the box with its database. And then the transfer to a backup machine if the database machine went down and coordinating with the various mid-tier boxes to have them route to the new location. It definitely can be done (or we could use oracle rac), we were just hoping to avoid it to keep the system easier to develop and administer.
-Nick On Wednesday, April 15, 2009, at 01:01PM, "Bryan Pendleton" <[email protected]> wrote: >> 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 > >
