In the TypeORM versions smaller than 0.3.0 you could create normal connections:
const createdConnection: Connection = await createConnection(options);
And then, this connection was usable like this:
MyModel.useConnection(connection);
And the connection could be closed without any problems after the database tasks were complete:
connection.close();
I´ve never had any issues regarding connection pooling in previous versions of typeorm.
But since the 0.3.0 update (now i´m on 0.3.7) i´m constantly getting the error
Pool is closed
It seems to me, that the datasource type does not act independently anymore, like the connection type did in the previous versions.
Is there a way to get this behaviour back?
Related
I am using postgresql-12 and the latest version of timescaledb as an extension for the database. Everything goes smoothly on the primary node. But when I tried to establish a stand by for the instance, the standby instance works out perfectly except the database using timescaledb extension, when I tried to connect to the database using client or command line, it immediately throws 'OID lookup failed for table "_timescaledb_catalog.dimension_partition"'.
It looks like the replication procedure somehow forget to sync table "_timescaledb_catalog.dimension_partition", but how? Does anyone even have a clue?
I have Delphi application with TZConnection in AutoCommit mode (connecting to the Firebird 3.0) in the global DataModule, this single connection serves all the queries in all the datamodules of the application.
But I have the problem, that the queries see only the data that were committed during the connection phase and queries do not the the new/fresh data that are coming either from the other application instances or from the other components (e.g. IBX datasetes) of the same application.
TZConnection.Reconnect solves this problem, but I am not sure what happend with the other open forms during such hard Reconnect.
Mostly it would be so nice to have TZonnection.CommitRetaining or RollbackRetaining procedures (similar to what IBX TIBTransaction have), but TZConnection do not have such functions and even TZConnection.Commit does not work in AutoCommit mode (the error is raised that Commit is incompatible with AutoCommit mode).
So - what is the best practice how to get fresh data using TZConnection. I would be happy to execute some function on the TZonnection upon opening new DataModule or upon client request for the new report.
Setting TZConnection TransactionIsolationLevel property to tiReadCommitted and AutoCommit to true solves the problem.
See error from console:
WebSocket connection to 'ws://localhost:8090/vaadinServlet/PUSH?v-uiId=0&v-csrfToken=27328352-6365-44a4-b980-1ca2d7a5bc1c&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.3.2.vaadin1-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true' failed: Error during WebSocket handshake: Unexpected response code: 200
This is after upgrading to vaadin 8.0.0
Push annotation and manual enabling of Push do not seem to make a difference. It reverts to long polling.
My best guess is it is a version problem. You can see it mentions atmosphere 2.3.2 in the error, but vaadin-push 8.0.0 imports atmosphere 2.5.4
As of my understanding vaadin does have two atmosphere products integrated within vaadin-push, both forked by vaadin. One for the server side (https://github.com/vaadin/atmosphere) and one for the client side (https://github.com/vaadin/atmosphere-javascript). I assume that they do not need to be in sync. E.g. I saw that atmosphere-samples-2.4.2 has been released using atmosphere-2.4.2 and atmosphere-javascript-2.3.0.
There's also an issue https://github.com/vaadin/framework/issues/8734, which states about the problem with vaadin-push through websocket (and also the version question). Hopefully they take care of this soon.
When using a TIBDatabase to connect to a firebird 1.5 database. When doing it statically from within the XE4 environment it connects fine and can open a table. However if I try and connect dynamically from a running exe, using the same connection params I get a "Username and Password undefined" error. This has surfaced as a new error as previous builds of the same application work fine, but now reverting to the same code causes an error.
Even the most basic of test apps gives the same problem, as soon as it is running as an exe it fails to be able to be connected using the same login and password.
There have been no known changes to the Database engine installation, no OS updates, and environment upgrades.
I'm using the latest indy snapshot (installed yesterday) and newest SSL libraries.
When trying to send a mail using idSMTP, the first time the component connects, I get an exception:
Could't load the SSL libraries
. Funny thing is, a retry works always. Debugging I found that the problem is in IsSSLOpenSSLHeader, function Loaad: boolean, line
#OpenSSL_add_all_algorithms := LoadFunctionCLib('OpenSSL_add_all_algorithms');
Why does it fail the first time and not the second is still a mystery to me, but before I go on investigating I would like to as if anybody knows the solution to this problem.
The code you are using is NOT the latest snapshot. That bug was fixed a couple of weeks ago. The line you quote is NOT in the latest code, it has been replaced with the following:
fn_OPENSSL_add_all_algorithms_noconf = 'OPENSSL_add_all_algorithms_noconf';
fn_OpenSSL_add_all_algorithms = 'OpenSSL_add_all_algorithms';
#OpenSSL_add_all_algorithms := LoadOldCLib(fn_OpenSSL_add_all_algorithms, fn_OPENSSL_add_all_algorithms_noconf);
I'm using Delphi XE-1 on Win 7/64, with the SSL and Indy that are installed by default. This week I had to do some work with SMTP and SSL, and I ran into the same problem you reported. Our application is somewhat complex and is already live and deployed in several locations and it uses Indy at several points in the code, so installing a newer version of Indy and rebuilding etc, was not very palatable.
Since the problem only arises on the first pass, I traced through some of the code and came up with this simple, painless workaround:
smtpClient.connect;
smtpClient.disconnect;
smtpClient.connect;
if not smtpClient.Authenticate then
raise ...
smtpClient.Send(msg);
Once you call connnect and then disconnect, the SSL libraries are loaded, so on your second call to connect you're good to go.
Works fine.