Re: [firebird-support] Multiple Embedded Connections
Alan McDonald wrote: > > "Windows Embedded now contains a SuperClassic instead of a SuperServer > > engine. > > File locks are shared, so a database can be accessed by one or more > > Embedded servers and a regular Classic or SuperClassic server at the same > > time. > > Consult the Firebird 2.5 Release Notes for full details." > > Yes - but where is this global lock table? It doesn't tell me if it's a file > somewhere or in the memory of the first server loaded? Iirc, it's a lock file in ProgramData\Firebird. Paul Vinkenoog
RE: Re[2]: [firebird-support] Multiple Embedded Connections
> Hello, Paul, Alan! > > PV> "Windows Embedded now contains a SuperClassic instead of a > SuperServer engine. > PV> File locks are shared, so a database can be accessed by one or more > PV> Embedded servers and a regular Classic or SuperClassic server at the > same time. > PV> Consult the Firebird 2.5 Release Notes for full details." > > Yes, but this provocates some people to use embedded for multi-tier > middleware, where definitely server (not embedded) must be used. > > AM> It appears that updates from one process are visible to the other(s) > AM> but I'm not sure how the second would know if a transaction is being > AM> managedin the first - is there a lock file being written to somewhere > that I can't find? > > I need to note that Embedded Firebird is a dll that works in an address space > of it's caller (exe). Thus EXE itself becomes "server". > And if that "server" have bugs, chances to get broken database are much > higher, especially if you want to use multiple exe+embedded on one DB. I don't want to use it like this - I just want to know how it's working. As far as corruption is concerned, I've used the embedded version for years and this possibility seems moot to me - I've never experienced corruption - escpeialy not in the single user/embedded databasesetup. Alan > > -- > Dmitry Kuzmenko, www.ib-aid.com > > > > > > ++ > > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > > Yahoo Groups Links > > >
RE: [firebird-support] Multiple Embedded Connections
> Hi Alan, > > > I notice that it is now possible to connect to a database via the > > embedded server and simultaneously connect via other embedded > > processes to the same database file. This was not possible in previous > > version - the second process would be locked out. > > > > Can someone lead me to an explanation of how these multiple > > connections are managed? Which embedded server will coordinate > updates > > and modifications to the database? > > > > It appears that updates from one process are visible to the other(s) > > but I'm not sure how the second would know if a transaction is being > > managedin the first - is there a lock file being written to somewhere that I > can't find? > > > > (WIN32) V2.5 > > From the 2.5 Quick Start Guide: > > "Windows Embedded now contains a SuperClassic instead of a SuperServer > engine. > File locks are shared, so a database can be accessed by one or more > Embedded servers and a regular Classic or SuperClassic server at the same > time. > Consult the Firebird 2.5 Release Notes for full details." Yes - but where is this global lock table? It doesn't tell me if it's a file somewhere or in the memory of the first server loaded? Alan > > Cheers, > Paul Vinkenoog > > > > > ++ > > > Visit http://www.firebirdsql.org and click the Resources item on the main > (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > > Yahoo Groups Links > > >
Re[2]: [firebird-support] Multiple Embedded Connections
Hello, Paul, Alan! PV> "Windows Embedded now contains a SuperClassic instead of a SuperServer engine. PV> File locks are shared, so a database can be accessed by one or more Embedded PV> servers and a regular Classic or SuperClassic server at the same time. PV> Consult the Firebird 2.5 Release Notes for full details." Yes, but this provocates some people to use embedded for multi-tier middleware, where definitely server (not embedded) must be used. AM> It appears that updates from one process are visible to the other(s) but I'm AM> not sure how the second would know if a transaction is being managedin the AM> first - is there a lock file being written to somewhere that I can't find? I need to note that Embedded Firebird is a dll that works in an address space of it's caller (exe). Thus EXE itself becomes "server". And if that "server" have bugs, chances to get broken database are much higher, especially if you want to use multiple exe+embedded on one DB. -- Dmitry Kuzmenko, www.ib-aid.com
Re: [firebird-support] Multiple Embedded Connections
Hi Alan, > I notice that it is now possible to connect to a database via the embedded > server and simultaneously connect via other embedded processes to the same > database file. This was not possible in previous version - the second > process would be locked out. > > Can someone lead me to an explanation of how these multiple connections are > managed? Which embedded server will coordinate updates and modifications to > the database? > > It appears that updates from one process are visible to the other(s) but I'm > not sure how the second would know if a transaction is being managedin the > first - is there a lock file being written to somewhere that I can't find? > > (WIN32) V2.5 >From the 2.5 Quick Start Guide: "Windows Embedded now contains a SuperClassic instead of a SuperServer engine. File locks are shared, so a database can be accessed by one or more Embedded servers and a regular Classic or SuperClassic server at the same time. Consult the Firebird 2.5 Release Notes for full details." Cheers, Paul Vinkenoog
[firebird-support] Multiple Embedded Connections
I notice that it is now possible to connect to a database via the embedded server and simultaneously connect via other embedded processes to the same database file. This was not possible in previous version - the second process would be locked out. Can someone lead me to an explanation of how these multiple connections are managed? Which embedded server will coordinate updates and modifications to the database? It appears that updates from one process are visible to the other(s) but I'm not sure how the second would know if a transaction is being managedin the first - is there a lock file being written to somewhere that I can't find? (WIN32) V2.5 Regards Alan McDonald
