db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Puz <nick.de...@me.com>
Subject Re: Stored Prepared Statements? -- Thoughts on exposing StorablePreparedStatements to user/external statements
Date Wed, 15 Apr 2009 21:37:10 GMT
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" <bpendleton@amberpoint.com>
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
>
>

Mime
View raw message