[firebird-support] Re: Object dependencies in Firebird OO API
Dimitry Sibiryakov s...@ibphoenix.com [firebird-support] a écrit : >Hello, All. > >In the description of OO API I failed to find if objects (classes) are > depended or not.I.e. I would like to know if order of releasing of them > matters. Can I release IProvider before IAttachment and IAttachment before > IStatement or it is required to release acquired interfaces before the > interface it was got from? > Hello, Personally, I release my classes in the opposite directions to their creation. coordialement Norbert -- Norbert Saint Georges http://tetrasys.fi ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
AW: [firebird-support] Scalability of connection numbers of client-server solution with Firebird 3.0?
Firebird has no limit. But Windows Sockets. http://www.firebirdfaq.org/faq292/ Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Gesendet: Mittwoch, 19. Februar 2020 08:18 An: firebird-support@yahoogroups.com Betreff: [firebird-support] Scalability of connection numbers of client-server solution with Firebird 3.0? Hi! I have set of Delphi applications that uses IBX and Zeos for connecting to Firebird 3.0 server. Some are direct client-server solutions (i.e. Delphi application uses IBX or Zeos components to open connection on the Firebird server) and some are 3-tier applications which have Delphi server and Delphi client (TClientDataSet is used for communication), but this server again uses IBX and Zeos. Just wanted to know - can there be any scalability issues. Currently we have some 30-40 concurrent connections, but their number can grow to 80, I guess - no more than 100. I remember from old days (back to ~2006, Firebird 1.0/Interbase 6.0/Firebird 1.5 times) that the high number of DB connections (around 50 and more) could hurt performance very much and very little could be done. Just wanted to check the current situation? Other databases have similar restrictions on the number of connections https://stackoverflow.com/questions/3733688/database-concurrent-connections-in-regard-to-web-http-requests-and-scalability and I wonder what is the best practice for Firebird with Delphi? The usual architecture for my client-server Delphi application is that I have one TIBDatabase and/or TZConnection per Delphi application and that is why MON$ATTACHMENTS usually show 1-2 attachments for each user. I guees - this is correct and I can simply can not make more optimization here - application should have 1-2 connection and there can not be any more pooling-type optimization here, am I right? For the 3-tier applications I have 1-2 connections for TDataModule and each TDataModule servers one user and those TDataModules are pooled with their connections preserved. Ususally I have 20-30 connections from my 3-tier application. Recently we increase the number of users/connections (as I said - to 50-80) and I am worrying now what can happen, should I be ready for emergence of some concerns? Just wanted to be prepared. And generally: - what are the limits on the number of Firebird connections/attachments? Should I be concerned about those limits if we will not have more than 100-150 Firebird connections? - what are pooling options for Firebird or Yii PHP application? Usually I think that pooling is very complex issue but maybe it is not? thx J.L. ub.unitel GmbH, Schulstraße 16, 06792 Sandersdorf-Brehna Geschaeftsfuehrung Klaus Richter, Olaf Meyer Amtsgericht Stendal HRB 26389 FA Bitterfeld Steuernr. 116/107/08597 Ust.identNr. DE815796778 Deutsche Bank IBAN DE53 86070024 0 6143234 00 Kreissparkasse Anhalt-Bitterfeld IBAN DE69 80053722 0 3050326 82 _ Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs- äußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung von ub.unitel GmbH dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. _
[firebird-support] Re: Firebird Embedded access permissions problem?
Hello, Mainly using Delphi 10.3.3 and Firebird 3 & 4 in embebded mode without any problem with the only difference that I do not use firedac (too much incomprehensible error). Maybe a clue to your problem. ps: I work with Firebird OO APIs Regards, Norbert -- Norbert Saint Georges http://tetrasys.fi ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re[2]: [firebird-support] Scalability of connection numbers of client-server solution with Firebird 3.0?
Hi First let me tell that I'm not Firebird expert, I can only share my experience. In one system I have desktop application based on IBObjects with concurrent users around 80-90 and REST service (for mobile application) based on ZEOS with around 10 concurrent connections. All is serverd by Xeon 1245 with SSD drives. Works like charm The second one is only desktop application also based on IBObjects with concurrent users around 50. This is server by some shitty virtual machine running Windows (don't ask why :-) ) but the performance is acceptable. From my point of view, if transaction processing is OK in application - the hardware of the server might be the source of performance degradation (less RAM, old HDD). Once I did a test on the machine from first system. We have started 200 connections each one performing non indexed queries in the loop, and than we started connection 201 from the application and started to work and performing daily user's task. Actually there no noticable difference between being only 1 user or one of 201. FireDAC, in my opinion will not improve anything. And finally I'd like to ask, what kind of benefit you get from COMMIT RETAINING? My $0.02 HTH Marcin -- Wiadomość oryginalna -- Od: "Jonatan Knud Lauritsen jonatan.laurit...@yahoo.dk [firebird-support]" Do: "firebird-support@yahoogroups.com" Data: 19.02.2020 09:20:55 Temat: RE: [firebird-support] Scalability of connection numbers of client-server solution with Firebird 3.0? I am trying to reply to Scalability of connection numbers of client-server solution with Firebird 3.0? 1. I am not receiving messages from the yahoo Firebird group (I don't want that they are coming in my mail, if I can always read them on the Web and in the the nice threaded format and with history), but I am not receiving answers to my questions as well - so - I don't know to how to respond them technically. I am not happy about mail lists really, forms and github issue formas are far more better way of communication. 2. I can do and I am doing proper transaction management with IBX/Firebird Zeos as well, no need for futher enhancements. Currentl y my MON$ATTACHMENTS lists some 30 connections and my MON$TRANSACTIONS lists some 20-25 transactions, no older than 20 minutes. I guess that is OK. Generally I open/close transaction for each read and save operation and when user inteacts with the form I am ussing COMMIT RETAINING options with the final COMMIT in the case when the form is being closed. I guess, that is right? That should be the proper balance that avoids long-running transactions and that also avoids recreating transactions for each minot save or read. Of course, I can migrate to FireDAC, but I don't see it as silver bullet for any improvement if the MON$ATTACHMENTS and MON$TRANSACTIONS data are good with the old IBX/Zeos as well. I can not see how can I improve it further? 3. And I have never understood (and I still not understand) what kind of dat a caching can be there for the ERP/accounting/manufacturing management systems? Either on the client side or on the server side. Well - my application caches (in detached, memory only ClientDataSets) some short, common classifiers like list of some document types, list of account codes, list or warehouses or the user preferences (all of which is load during the startup time of the application). But anything beyond that can not be cached: the catalog of goods is enormous - more than 20.000 - how can I cache it? Catalog of customer is still larger (more than 100.000). The list of documents is growing and so on, so on. I simply don't understand what miracles the FireDAC can do there? Will it make some AI analytics to decide some chunks of commonly used/rarely mutable data? I have great doubts about the possibility of such analytics and reliability of it. Database can do some caching based on the data access patterns, but not FireDAC. OK, I can understand caching for some web pages, web shops, newspages, but there is little that can be cached (automatically or manually) in ERP applications with OLTP and dynamic reports. Thx, J.
RE: [firebird-support] Scalability of connection numbers of client-server solution with Firebird 3.0?
I am trying to reply to Scalability of connection numbers of client-server solution with Firebird 3.0? 1. I am not receiving messages from the yahoo Firebird group (I don't want that they are coming in my mail, if I can always read them on the Web and in the the nice threaded format and with history), but I am not receiving answers to my questions as well - so - I don't know to how to respond them technically. I am not happy about mail lists really, forms and github issue formas are far more better way of communication. 2. I can do and I am doing proper transaction management with IBX/Firebird Zeos as well, no need for futher enhancements. Currently my MON$ATTACHMENTS lists some 30 connections and my MON$TRANSACTIONS lists some 20-25 transactions, no older than 20 minutes. I guess that is OK. Generally I open/close transaction for each read and save operation and when user inteacts with the form I am ussing COMMIT RETAINING options with the final COMMIT in the case when the form is being closed. I guess, that is right? That should be the proper balance that avoids long-running transactions and that also avoids recreating transactions for each minot save or read. Of course, I can migrate to FireDAC, but I don't see it as silver bullet for any improvement if the MON$ATTACHMENTS and MON$TRANSACTIONS data are good with the old IBX/Zeos as well. I can not see how can I improve it further? 3. And I have never understood (and I still not understand) what kind of data caching can be there for the ERP/accounting/manufacturing management systems? Either on the client side or on the server side. Well - my application caches (in detached, memory only ClientDataSets) some short, common classifiers like list of some document types, list of account codes, list or warehouses or the user preferences (all of which is load during the startup time of the application). But anything beyond that can not be cached: the catalog of goods is enormous - more than 20.000 - how can I cache it? Catalog of customer is still larger (more than 100.000). The list of documents is growing and so on, so on. I simply don't understand what miracles the FireDAC can do there? Will it make some AI analytics to decide some chunks of commonly used/rarely mutable data? I have great doubts about the possibility of such analytics and reliability of it. Database can do some caching based on the data access patterns, but not FireDAC. OK, I can understand caching for some web pages, web shops, newspages, but there is little that can be cached (automatically or manually) in ERP applications with OLTP and dynamic reports. Thx, J.
