Lifecycle of MQ Connection in JSF - Connection Closed - jsf-2

I use JSF 2 an WebSphere MQ for Messaging (JMS).
I want to know what's the best practice to open / close the QueueConnection?
Should I use for each client session one connection and open it on (post-)construction and close it on (pre-) destruction like here?
Or are there better ways to handle the connection? E.g. "Open EntityManager in View" Pattern for JDBC/JPA?

Avoid creating a new connection for each getMessage() invocation. Create one connection at construct time, save it as an instance variable.
For each getMessage() call, create a new session, get the message, then close the session.
When you're done, close the connection at destruction time.

Related

SignalR connection (hub proxy) lifetime

What is best practice for connecting clients to SignalR hub? In client, is it better to keep connection (hub proxy) somewhere, or is it better to create connection (hub proxy) for each hub method call?
Per https://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-server#multiplehubs
There is no performance difference for multiple Hubs compared to
defining all Hub functionality in a single class.
Whether or not you use multiple hubs is simply a matter of deciding how you want to logically organize your code. Standard OOP practices apply here.
Later in the same documentation...
If you need to use the context multiple-times in a long-lived object,
get the reference once and save it rather than getting it again each
time. Getting the context once ensures that SignalR sends messages to
clients in the same sequence in which your Hub methods make client
method invocations. For a tutorial that shows how to use the SignalR
context for a Hub, see Server Broadcast with ASP.NET SignalR.
...not sure if that last bit is relevant to what you're asking, but it's good to know as you plan your signalr architecture.
The optimal way to go is to keep just a single connection for all method calls. Every new connection you open will waste network resources and processing, as SignalR needs to keep a live connection with the server for each connection. That means battery drain on mobile devices and more server workload.
[UPDATE]
After reading #alex-dresko answer I realized my answer needs some clarification.
It doesn´t matter how many proxies you create under the same connection, it won´t change performance:
hubConnection = new HubConnection(BASE_ADDRESS);
var chatProxy = hubConnection.CreateHubProxy("chatHub");
var otherProxy = hubConnection.CreateHubProxy("otherHub");
var nProxy = hubConnection.CreateHubProxy("nHub");
However, you are asking if
is it better to keep connection (hub proxy) somewhere
Well, connection is one thing (HubConnection) and the proxy is another thing.
New connections will open a new bridge between the client and the server, so creating and persisting a single connection globally in your app makes sense. Then you can reuse the very same connection to create as many proxies as you want.
You can easily test this scenario. Create a console app that creates a connection and 2 proxy hubs. Then create 2 connections and 1 hub on each one and check the signalr logs...

Indy TCP Server Freezes, no idea why

I have a Server and a client (Delphi).
The client gets login details and then connects to the server sends them to the server to be validated, the server receives the data validates it then returns whether the given data is correct.
If the data was correct the client continues to the next window where they enter some data into corresponding fields and then sends the data to the server, when the server receives the data it stores it and then replies to the client that it stored it successfully. When the client has been notified that the data was stored successfully it displays a message notifying the user and then terminates.
While testing this, with the client running on four different computers, (Each computer would have opened and closed the client about 6 times) the server suddenly stops replying to the clients (Clients display message saying "Connection closed gracefully")
This is the error the server is returning:
So the error appears to be when ADOQuery opens the connection to execute the SQL, why would it cause a exception only after 30 executes?
Any Suggestions to what my problem is as I have no idea what it might be.
Thanks for your help :)
If a client receives a "Connection closed gracefully" error, it means the server closed that client's connection on the server side. If your server code is not explicitly doing that, then it usually means an uncaught exception was raised in one of the server's event handlers, which would cause the server to close the socket (if the exception is raised after the OnConnect event and before the OnDisconnect event, OnDisconnect is triggered before the socket is closed). TIdTCPServer has an OnException event to report that condition.
TIdTCPClient closes the socket during destruction if it is still open.
Update: TIdTCPServer is a multi-threaded component. Each client connection runs in its own thread. ADO uses apartment-threaded COM objects that are tied to the thread that creates them, and can only be used within that thread context unless marshaled across thread boundaries using CoMarshalInterThreadInterfaceInStream() + CoGetInterfaceAndReleaseStream(), or the IGlobalInterfaceTable interface.
In this situation, you should either:
give each client its own ADO connection and query objects. You could either:
A. create them in the OnConnect event and store them within the TIdContext for use in the OnExecute event, and then free them in the OnDisconnect eventt. Or just create and free them in the OnExecute event on an as-needed basis.
B. derive a new class from TIdThreadWithTask and override its virtual BeforeExecute() and AfterExecute() methods to create and free the ADO objects, and then assign one of the TIdSchedulerOfThread... components to the TIdTCPServer.Scheduler property and assign your thread class to the TIdSchedulerOfThread.ThreadClass property. Then, in the server events, you can use TMyThreadClass(TIdYarnOfThread(TIdContext.Yarn).Thread) to access the calling thread's ADO objects.
Create a separate pool of ADO objects. When a client needs to access the database, have it marshal the appropriate ADO objects to the calling thread's context, and then put the objects back in the pool when finished.
Either way, since ADO is COM-based, don't forget to call CoInitialize/Ex() and CoUnintialize() for each client thread that needs to access ADO objects, either in the OnConnect and OnDisconnect events, or in the TIdThreadWithTask.BeforeExecute() and TIdThreadWithTask.AfterExecute() methods.

How to prevent ADODB.Connection pooling?

I'm using Powershell v2.0, question is in the title. I'm having to use the old school ADOB.Connection (not the OLEDB provider) to open a Jet DB file (.mdb). The reason is simple, the ADODB.Connection exposes properties I need access to that the OLEDB provider doesn't.
I'm opening the DB via ADOB.Connection to query for some information, and then I'm trying to compact the DB using JRO.JetEngine. The issue is that I keep getting an error about the Jet DB being locked.
I'm explicitly calling Close on it, and setting the variable to $null, and still experiencing that issue. My best guess is that ADODB.Connection is using connection pooling, and so is not releasing the resources the way it should be.
According to http://support.microsoft.com/kb/191572, the call to close() should be enough, but it doesn't seem to be working.
Is there a way for me to explicitly specify no connection pooling when creating ADODB.Connection objects?
In the link you provided, it is said that calling to close returns the connection to the pool:
2.What statement returns the connection to the pool?
2.Conn.Close
You might need to destroy/dispose the ADODB.Connection object, so that it is removed from the pool, or, if you are using OLE DB as the provider, configure the OLEDB Services, as explained here:
Enabling OLE DB Resource.
Pooling Resource pooling can be enabled in
several ways:
For an ADO-based consumer, by keeping one open instance of a
Connection object for each unique user and using the OLEDB_SERVICES
connection string attribute to enable or disable pooling. By default,
ADO attempts to use pooling, but if you do not keep at least one
instance of a Connection object open for each user, there will not be
a persistent pool available to your application. (However, Microsoft
Transaction Server keeps pools persistent as long as the connections
in them have not been released and have not eventually timed out.)

Do I need to call close connection?

In the application I use Doctrine_Query::create() many times.
Do I need to call close connection each time I use it? Or will doctrine do it for me ?
Creating a query does not make a new connection, so you don't need to worry at all. There is a single connection established each request by the Doctrine connection manager, and all your queries will go over that connection.
Each query is sharing the same connection. There is no need to close it.
You can examine Doctrine_Manager to see how this is done.

With groovy.sql.newInstance in grails - who closes the connection and when?

I'm using grails but I have lot's of stored procedures I'm trying to call from groovy.Sql.newInstance...
In all the examples I've found I never see anyone actually calling close on the connection. But when I tried running a bunch of methods within one response that each uses its own call to newInstance, then it got an error that there were too many connections. That leads me to believe that it isn't pooling the connections. That's a bummer. So do people create one connection and pass it around? Does grails and groovy close the connection at the end of the request?
I don't think that the connection is automatically closed after a request (which wouldn't be cool either), but you can manually close the connection used by the Sql instance:
Sql sql = Sql.newInstance("jdbc://...")
// some queries
sql.close()
See the JavaDoc.
If you would like to use pooled connections (which is surely a good idea), you should be able to create a pooled BasicDataSource (as Spring bean) and use the Sql(DataSource dataSource) constructor of Sql, rather than newInstance().

Resources