Menu
▾
▴
firebird-devel
|
From: Olivier M. <om...@ti...> - 2004-06-08 22:27:03
|
Nando Dessena wrote: > I don't want the firebird server to be available for anyone to stop it > or even see it. I don't want anyone perceiving that something called > "firebird" exist on the machine, except from the "powered by firebird" > logo in my application's about box. I want to run (as an application) > on machines that don't support services (Win98). I want to be able to > seamlessly install on machines which already have IB and/or Fb > installed and running, without causing harm to them. Plus I want all > the other things that I have already explained, of which the ability > to ensure that Fb get woken up when my service starts is but the tip > of the iceberg. > > If anyone can come up with a different solution that allows all this > I'd be happy to hear. I use FB SS executable as compiled and provided by the Project download area (no private build). The setup of the end-user application installs bits of a typical FB SS distribution to one of the application folders. Setting up a NT service for the SS (if services available). The end-user application while starting up, takes care to start that FB copy as an application if not configured as a service or checks that FB service runs and starts it. Guardian is not shipped/used. The end-user application does the pampering. Of course config files shipped use different tcp/ip ports than standards and some other settings so that this "private" copy of FB on any machine does not conflict with any other one. I can install to a server without having to care wether another FB or IB is already installed other there. Nothing is copied to System directories. The end-user application knows where to find local client DLL. And knows where to find private copies of tools needed. That's as close as I can get to your requirements without touching a single line of code of FB, be it engine code, server code or even its build procedures. Might help you as a not_that_bad alternative. [ This is all on Windows. I suppose similar configuration efforts should be possible on Linux. I used to know those systems but named them Unix by that time. ;-) ] -- Olivier Mascia |
|
From: Nando D. <na...@de...> - 2004-06-09 04:21:03
|
Olivier, O> I use FB SS executable as compiled and provided by the Project download O> area (no private build). The setup of the end-user application installs O> bits of a typical FB SS distribution to one of the application folders. O> Setting up a NT service for the SS (if services available). The end-user O> application while starting up, takes care to start that FB copy as an O> application if not configured as a service or checks that FB service O> runs and starts it. Guardian is not shipped/used. The end-user O> application does the pampering. Of course config files shipped use O> different tcp/ip ports than standards and some other settings so that O> this "private" copy of FB on any machine does not conflict with any O> other one. I can install to a server without having to care wether O> another FB or IB is already installed other there. Nothing is copied to O> System directories. The end-user application knows where to find local O> client DLL. And knows where to find private copies of tools needed. This is almost exactly what I am doing now, except that I always run the firebird server as an application even in the cases in which my own app runs as a service (ie it starts fb with CreateProcess). My path is one of least possible impact on the system (I don't use the windows registry, for example, except for the required service registration of my app). O> That's as close as I can get to your requirements without touching a O> single line of code of FB, be it engine code, server code or even its O> build procedures. I have come to the same conclusion. Then I thought it could be streamlined a bit. ;-) O> Might help you as a not_that_bad alternative. Yep, that's actually what I currently have. But since I think the ddl server would be useful to many I still think there's value in building it. O> [ This is all on Windows. I suppose similar configuration efforts should O> be possible on Linux. I used to know those systems but named them Unix O> by that time. ;-) ] Doesn't time fly? ;-) Ciao -- Nando Dessena mailto:na...@de... |
|
From: Olivier M. <om...@ti...> - 2004-06-09 07:14:07
|
On 9/06/2004 6:23 GMT+1, Nando Dessena wrote: > O> Might help you as a not_that_bad alternative. > > Yep, that's actually what I currently have. But since I think the ddl > server would be useful to many I still think there's value in > building it. This is here where my requirements diverge from yours. For nothing on this earth would I want to host the engine in my application process space by loading wether the current embedded DLL or the discussed so-called embedded superserver DLL. Why ? For protection. I don't want a bug in the FB DLL to pollute my process space and I wouldn't want to risk my users data by having my own host application one day go mad and pollute the memory used by the engine DLL. That could mean database corruption. There are enough external causes that could mean corruption to add my own server application to the list of threats. Having my isolated own copy of the server is important (for ease of support, configuration, upgrades and so on). But having it run as a distinct process than my application is even more important. And in my case, the current added level (tcp/ip) of communication layers between both is well worth the added security. Yours, -- Olivier Mascia |
|
From: Nando D. <na...@de...> - 2004-06-09 09:38:56
|
Olivier, O> For nothing on this earth would I want to host the engine in my O> application process space by loading wether the current embedded DLL or O> the discussed so-called embedded superserver DLL. OK. Yours is a perfectly respectable concern and you are of course entitled to it. But, it is slightly off target for this discussion, in that it's a point against fbembed as well as it is against my proposed solution. My proposal assumes that the pros and cons of hosting the server (be it fbembed or this new beast) in another application's address space are well understood. O> Why ? For protection. I don't want a bug in the FB DLL to pollute my O> process space and I wouldn't want to risk my users data by having my own O> host application one day go mad and pollute the memory used by the O> engine DLL. BTW I had this same concern about fbembed when it was first released. Ann and others once reassured me (because I saw things from an even more pessimistic POV then) and I have come to the conclusion that, once you evaluate the benefits and risks of using fbembed, you can still find some cases in which you can use it. The same applies to the "loadable superserver" idea. Ciao -- Nando Dessena mailto:na...@de... |
|
From: Leyne, S. <Se...@br...> - 2004-06-08 19:24:50
|
Roman and Nando, > > c) the same server process that serves database connections needs to > > provide other services to remote clients, using different ports and > > protocols, including but not limited to SOAP and HTTP. For those who > > are concerned about the scalability of my all-in-one solution, don't > > worry: The workload is never going to be heavy. >=20 > It was not intended to be your case :) Since Sean is not buying c), I > created a case, pretty legal one, when Jim's solution is the only possible > one. Maybe he buys this one :) Nope. Just to be clear, what I don't "buy" is the need expressed. Ironically, my BroadView application and Nando's are very similar. It provides an extensive set of functions and services to applications (via DCOM, SOAP...). We also provide selected remote applications direct database access. Accordingly, our application is equally dependant on the FB service/server. But the functionality that Nando is suggesting seems to run counter to the appropriate "layering" of the solution. If you want to embed the database into your application than you wrap the application around the engine -- fine. This means that no outside access is provides to your 'closed' environment or you must expose your own server functions to expose/manage the database access. He wants to completely surround the engine but still provide external 'native' access to the engine. This appears to be a contradiction. Sean |
|
From: Jim S. <ja...@ne...> - 2004-06-08 19:43:23
|
Leyne, Sean wrote: >But the functionality that Nando is suggesting seems to run counter to >the appropriate "layering" of the solution. > >If you want to embed the database into your application than you wrap >the application around the engine -- fine. This means that no outside >access is provides to your 'closed' environment or you must expose your >own server functions to expose/manage the database access. > >He wants to completely surround the engine but still provide external >'native' access to the engine. This appears to be a contradiction. > > > Sean, there really isn't a contradiction. The entire system is architected around the idea that the remote interface/server combination is a transparent piece of plumbing. There should be no theoretical or practical problems with an application performing direction database access fire off some threads to let other folks talk to the database running in his process other than the obvious one that database access isn't available when the application program isn't accessible. There is a problem (if I remember correctly) in Firebird up to and including head that the embedded build doesn't perform user authentication. This may provide the motivation to straighten out some conditionals in jrd.cpp, but it doesn't affect the plumbing. It's just code, folks. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: Nando D. <na...@de...> - 2004-06-08 20:09:38
|
Jim, J> There is a problem (if I remember correctly) in Firebird up to and J> including head that the embedded build doesn't perform user J> authentication. yep. But since the build I need is superserver rather than embedded this should not be a problem. ;-) It can do authentication: it has a root directory, a config file and a security database. J> It's just code, folks. Amen. Ciao -- Nando Dessena mailto:na...@de... |
|
From: Nando D. <na...@de...> - 2004-06-08 20:06:33
|
Sean, S> Ironically, my BroadView application and Nando's are very similar. unless yours is mainly a legacy C/S application that cannot be converted to proper 3-tier layered architecture any soon, it is installed at some 20K sites and has to work on every version of Windows known to mankind, they are not really that similar. ;-) S> our application is equally dependant on the FB S> service/server. Yes. S> But the functionality that Nando is suggesting seems to run counter to S> the appropriate "layering" of the solution. Yes, it seems so. But I have already stated why I need things this way. Mine is an *embedded* solution, which means that the logical layers are all there, but they melt into a single physical executable program. This is what I call "embedded". I have no control on what kind of machines it is going to work on. It has to work both as a service and as an application, it has to be managed by simply starting an application and stopping the very same application when work is done, it has to peacefully coexist with whatever version(s) of IB/Fb, past, present and future the user might decide to install on the machine, in short: it has to work, always. Due to the costs in terms of customer support that every little glitch (as little as "I have seen a process called fbserver.exe on the Task Manager, I thought it was a virus and I have terminated it") will cause, I need to cut the possible causes of problems. Having two (more or less) synchronized processes to do what's essentially an embedded thus by definition monolithic service is suboptimal in this respect. I appreciate that there are development and deployment scenarios which are totally different; as a consultant, I have seen many. I also understand that it might be difficult to imagine and understand situations that are so unusual to us. S> If you want to embed the database into your application than you wrap S> the application around the engine -- fine. This means that no outside S> access is provides to your 'closed' environment or you must expose your S> own server functions to expose/manage the database access. FWIW this would be my first choice if I didn't have to a) support a legacy client application that cannot be easily converted, and b) provide access to external reporting and datawarehousing tools through ODBC and the like. So my server has to talk firebird's wire protocol one way or the other. S> He wants to completely surround the engine but still provide external S> 'native' access to the engine. This appears to be a contradiction. It might appear so, but I hope I have finally made it clear why it actually isn't. Bring "embedded" one step further. People is going to use it. It *does* make sense, and a lot of sense. Firebird is the *only* enterprise class database that could possibly do it, and we're still here discussing whether we should allow it or not. Let the developer decide what's more appropriate in every particular situation (AFAIK you sponsored the WITH LOCK feature, you should understand what I mean). Ciao -- Nando Dessena mailto:na...@de... |
|
From: Nando D. <na...@de...> - 2004-06-04 18:39:29
|
Sean, S> That functionality is know as a "full engine" Sure. What I need is a "full engine" built as a dynamic library. If it had the functionality of fbembed as well, that would be a bonus and a performance boos for "internal" requests, but it's not mandatory. I'll put it another way: I need to augment the firebird server and I need to deploy, if possible, a single server process. If my clients didn't need to talk to the Firebird server through TCP/IP I would go with embedded and wouldn't mind, but unfortunately that's not the case. Currently I have two processes (mine and fbserver.exe) that I need to keep synchronized (in terms of startup and shutdown, mainly), which is getting difficult without a third process acting as a "guardian". The only advantage of my current solution/workaround is that, since it's made up of two processes, is more SMP-friendly. :-) So you can see it from several different POVs, but the technical details stay the same, I believe. I'm curious to know what core devels like Dmitry or Nickolay think about Jim's 6 months estimate... Ciao -- Nando Dessena mailto:na...@de... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X