Re: [Firebird-devel] FBJava plugin issues
> > Hello Mark, > > > > Here it is what we did in details: > > > > 1) Install plugin into C:\Firebird_Java\fbjava-1.0.0-alpha-1. > > I advice to prefer use the version of master instead of alpha-1. > > Yes, it's not released as binary yet, but important fixes and many changes has > done since then. > > I will build and publish it when time permits. What does "when time permits" mean? We are trying to implement application functionality which requires this feature, that response gives us no timing for when the issue will get attention. Sean -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
21.05.2018 14:58, Rashid Abzalov wrote: 21.05.2018 14:42, Vlad Khorsun via Firebird-devel wrote: I don't see how persistent connections in Postgres could be reused by different user sessions. No, in Postgres you can reuse only your own connections. You see - all approaches have its weak and strong points :) Nevertheless, it seems to me that this approach also solves the original task that faced the implementation of the connection pool. Not agree. Connection pool allows to minimize number of simultaneously open external connections. Also it allows to avoid cost of connect\disconnect in case of many short-lived user connections actively works with external data sources. And this was the main goal as users complains on performance. But you do not need to deal with the side effects of managing this pool by the system, not the user. Because reset the state of the session is half the task, and often this will not solve the problem, because sometimes you need to execute queries in the context of the previous state. That is, on a good need to implement a reset state somewhere out, and then restore it from there (on request or maybe always). It makes sence. But currently we have no way to reuse external connection and there is no existing applications that depends on external connection state. Probably we should take into account this PG feature when (if) implement persistent external data sources. Regards, Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
21.05.2018 14:42, Vlad Khorsun via Firebird-devel пишет: I don't see how persistent connections in Postgres could be reused by different user sessions. No, in Postgres you can reuse only your own connections. Nevertheless, it seems to me that this approach also solves the original task that faced the implementation of the connection pool. But you do not need to deal with the side effects of managing this pool by the system, not the user. Because reset the state of the session is half the task, and often this will not solve the problem, because sometimes you need to execute queries in the context of the previous state. That is, on a good need to implement a reset state somewhere out, and then restore it from there (on request or maybe always). -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
21.05.2018 14:25, Rashid Abzalov wrote: Instead of implementing a pool of connections that the system implicitly manages, it might be better to implement named connections as it is done in Postgres (https://www.postgresql.org/docs/current/static/contrib-dblink-function.html)? Which the user manages and re-uses as he needs - he knows with which tables and context variables he already worked, and brings them to the desired state. I don't see how persistent connections in Postgres could be reused by different user sessions. Regards, Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
Instead of implementing a pool of connections that the system implicitly manages, it might be better to implement named connections as it is done in Postgres (https://www.postgresql.org/docs/current/static/contrib-dblink-function.html)? Which the user manages and re-uses as he needs - he knows with which tables and context variables he already worked, and brings them to the desired state. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5832) Implement way to reset user session environment to its initial (default) state
Implement way to reset user session environment to its initial (default) state -- Key: CORE-5832 URL: http://tracker.firebirdsql.org/browse/CORE-5832 Project: Firebird Core Issue Type: New Feature Components: Engine Reporter: Vlad Khorsun Resetting user session (connection) to its initial state should be useful when session is reused by application. I.e. instead of detach\attach application could just reuse already established connection. To reuse connection all its user context variables, contents of temporary tables etc should be cleared and all session-level settings should be reset to its default values. The proposed solution is to implement new session management SQL statement ALTER SESSION RESET It will - reset DECFLOAT parameters (BIND, TRAP and ROUND) to its default values - reset session and statement timeouts to zero - remove all context variables in 'USER_SESSION' namespace - clear contents of all used GLOBAL TEMPORARY TABLE ... ON COMMIT PRESERVE ROWS - restore ROLE which was passed with DPB and clear all cached security classes (if role was changed) Note, CURRENT_USER will not be changed. See also discussion at fb-devel, thread "RFC: External Connections Pool" started at 18.05.2018 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5831) Not user friendly output of gstat at encrypted database
Not user friendly output of gstat at encrypted database --- Key: CORE-5831 URL: http://tracker.firebirdsql.org/browse/CORE-5831 Project: Firebird Core Issue Type: Bug Components: GSTAT Affects Versions: 3.0.3 Reporter: Vlad Khorsun Priority: Minor Gstat shows "strange" lines "Variable header data" section at on encrypted database: > gstat -h ... Database header page information: .. Implementation HW=Intel/i386 little-endian OS=Windows CC=MSVC Shadow count0 Page buffers2048 Next header page0 Clumplet End216 Database dialect3 Creation date Sep 7, 2017 15:41:14 Attributes force write, encrypted, crypt process, plugin cryptDB Variable header data: Encoded option 5, length 28 Key hash: Y57pr6T1PsnNkgLpaIVupsmvhmM= Unrecognized option 11, length 16 Sweep interval: 0 *END* Look at 1st and 3rd liens after "Variable header data" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
21.05.2018 11:47, Dimitry Sibiryakov wrote: 21.05.2018 10:13, Mark Rotteveel wrote: if pool contain connection to database 1 and user try to connect to also database 1 he can use pool instead normal connection. That wouldn't really work Yes, that wouldn't work. But generally speaking pools in Y-valve could be potentially a little more useful than in engine. For Web-applications for example. In general - i agree. But usually Web-applications uses connection pools provided by frameworks, afaiu. But this is out of this topic. Sure ;) Regards, Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
21.05.2018 10:13, Mark Rotteveel wrote: if pool contain connection to database 1 and user try to connect to also database 1 he can use pool instead normal connection. That wouldn't really work Yes, that wouldn't work. But generally speaking pools in Y-valve could be potentially a little more useful than in engine. For Web-applications for example. But this is out of this topic. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: External Connections Pool
On 20-5-2018 17:24, Vlad Khorsun via Firebird-devel wrote: 20.05.2018 14:15, Mark Rotteveel wrote: I would expect such a feature to reset all session state to the initial state on connect, including things like * Clear context USER_SESSION * Reset role to the initial role specified on attach * Reset other session configuration (eg DECFLOAT behavior, timeouts, session timezone, etc) Clear GTT's also. Yes, I didn't mention those as that was the starting point of the discussion. I want to emphasize more needs to be reset than just GTTs. Mark -- Mark Rotteveel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
