Hello Dimitry, On 17.03.2015 8:30, Dmitry Yemanov wrote: > 17.03.2015 01:02, Lauri Zoova wrote: >> >> After further investigation, it turns out the problem is NOT with >> context values getting lost but rather in the ON CONNECT database >> trigger not firing when connecting. Furthermore, so far it has always >> been the SECOND attachment to the db (by attachment id) after OS restart >> where connections trigger fails to run (the connection itself is >> successful and functional). > > It looks like some kind of client-side connection pooling is playing > against you. I.e. your second logical connection in fact reuse the first > physical connection. Did you check number of physical connections via > mon$attachments?
Yes, i am using mon$attachments and other monitoring tables for connections and context info checking. There is no connection pooling in the services. Three services are started with OS. Each has one connection. The services each have a critical section to ensure only one thread accesses the connection at any given time. -- BR, Lauri ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
