| Subject | Re: [IB-Architect] Classic vs SuperServer was IB/FB Lock manager failures |
|---|---|
| Author | Dalton Calford |
| Post date | 2002-09-24T16:40:02Z |
Curiosity,
Currently, superserver starts with the machine and only one copy runs,
regardless of the number of databases on the machine, while classic starts at
the time of connection, and again, runs a copy, ignoring the number of
databases on the machine.
What about a architecture that spawns like classic on the first connect to a
database, operates like superserver (handling all future connections) and
stays open until the last connection drops.
The immediate benefits are
1) if you are developing test code on one database and kill the server
process, you will not kill the process for other users
2) the first process spawned would put a physical lock on the file (limited by
OS/filesystem structure) and if another process attempts to connect with a
different path, a different SS process would start, try to open the file and
fail due to the initial lock - this would be a way of preventing some of the
corruption caused by invalid paths.
3) on multi-processor systems, you could specify the cpu the SS process per
database would operate - this would give some benefits of multi-cpu
threading.
future design benefits may include
a) the classic and superserver codebase to unify once again so it is a single
offering
b) shared disk/memory locking to allow for SS on clustered computing platforms
c) short term patch until the code base is re-written to have the granularity
needed for a SMP system.
I agree with Ann in that having two diverging code/implementation paths is a
death knell for the project, my suggestion is to merge both versus dropping
one over the other......
best regards
Dalton
Currently, superserver starts with the machine and only one copy runs,
regardless of the number of databases on the machine, while classic starts at
the time of connection, and again, runs a copy, ignoring the number of
databases on the machine.
What about a architecture that spawns like classic on the first connect to a
database, operates like superserver (handling all future connections) and
stays open until the last connection drops.
The immediate benefits are
1) if you are developing test code on one database and kill the server
process, you will not kill the process for other users
2) the first process spawned would put a physical lock on the file (limited by
OS/filesystem structure) and if another process attempts to connect with a
different path, a different SS process would start, try to open the file and
fail due to the initial lock - this would be a way of preventing some of the
corruption caused by invalid paths.
3) on multi-processor systems, you could specify the cpu the SS process per
database would operate - this would give some benefits of multi-cpu
threading.
future design benefits may include
a) the classic and superserver codebase to unify once again so it is a single
offering
b) shared disk/memory locking to allow for SS on clustered computing platforms
c) short term patch until the code base is re-written to have the granularity
needed for a SMP system.
I agree with Ann in that having two diverging code/implementation paths is a
death knell for the project, my suggestion is to merge both versus dropping
one over the other......
best regards
Dalton
On Tuesday 24 September 2002 7:36 pm, Ann W. Harrison wrote:
> At 01:55 PM 9/23/2002 -0400, Ann W. Harrison wrote:
> >We should be prepared for some work
>
> And what she meant to add was
>
> Maintaining two architectures will kill this project.
> It's just too hard to add a complex feature in a way
> that works on both classic and superserver. That's
> the source of a lot of conditional code, and as new
> stuff is added, it's going to break one version or the
> other.
>
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/