Do I need to close connection before response.end? - vbscript

In classic asp I have the file open.asp and close.asp included at top and bottom of every page. Somewhere I have response.end in my codes. Do I need to close connection before response.end or the server translates the page to the end of page after response.end?
Content of open.asp:
Set objcon = Server.CreateObject("ADODB.Connection")
objcon.connectionString="DSN=something"
objcon.Open
content of close.asp:
objcon.close
set objcon=nothing
Please note that I have no problem with multiple connections and memory leak. My exact question is about behavior of of server against "Response.End"

Response.End stops further execution of the page. From the docs: "The remaining contents of the file are not processed." So, no, the connection object won't get cleaned up in this scenario.
It's better to go ahead and create connection objects at a more granular level and destroy/release them as soon as possible back to the ADO connection pool, which is what manages the actual connections to the database. Reusing a connection object leaves it more vulnerable to not getting cleaned up properly.

Related

does jdbcTemplate close resultsets?

I have a spring application where its home page fire multiple ajax calls which in turn fetch data from the DB and return back. The DB has been configured with connection pooling with minPoolSize as 50 and maxPoolSize as 100.
now when I open the home page, around 7 connections are established with the DB, which is expected as around 7 ajax calls are made and I assume all create their own connection. Now when I refresh the page, I see 7 more new connection are established (I see total 14 physical connections from db2 monitoring), which seems to be unexpected, as I assume jdbcTemplate do close the connection after the query from the first access and refresh in this case should reuse the connections ?
Now question here is does resultsets are also getting closed by jdbcTemplate along with connection close ? or Do i need to explicitly close the resultSet so that connection can be closed automatically. Opened resultSet may be a reason of connection not getting close ? Attaching the code for connection pooling configuration
<dataSource jdbcDriverRef="db2-driver" jndiName="jdbc/dashDB-Development" transactional="true" type="javax.sql.DataSource">
<properties.db2.jcc databaseName="BLUDB" id="db2-dashDB-Development-props" password="********" portNumber="*****" serverName="*********" sslConnection="false" user="*****"/>
<connectionManager id="db2-DashDB-Development-conMgr" maxPoolSize="100" minPoolSize="50" numConnectionsPerThreadLocal="2"/>
My initial theory was that the reuse of the connection will happen only when minPoolSize is reached and till that time it will always create new physical connection. HOwever I see this behavior even after reaching that limit. I refreshed my page 10 time and I see 70 physical connections. Now my only doubt is that connection are somehow are not getting close and spring is seeing those connection busy ? This may be because resultsets are not closed or some other reason ? Is it a way to say jdbctemplate not to wait for closing resultset beyond a time limit ?
Thanks
Manoj
If you look at the org.springframework.jdbc.core.JdbcTemplate.query method source code you see calls to -
JdbcUtils.closeResultSet(rs);
In the finally blocks - so yes JDBCTemplate does call rs.close
The template also closes or returns the connection to the pool

How can I tell if my Ruby server script is being overloaded?

I have a daemonized ruby script running on my server that looks like this:
#server = TCPServer.open(61101)
loop do
#thr = Thread.new(#server.accept) do |sock|
Thread.current[:myArrayOfHashes] = [] # hashes containing attributes of myObject
SystemTimer.timeout_after(5) do
Thread.current[:string] = sock.gets
sock.close
# parse the string and load the data into myArrayOfHashes
Myobject.transaction do # Update the myObjects Table
Thread.current[:myArrayOfHashes].each do |h|
Thread.current[:newMyObject] = Myobject.new
# load up the new object with data
Thread.current[:newMyObject].save
end
end
end
end
#thr.join
end
This server receives and manages data for my rails application which is all running on Mac OS 10.6. The clients call the server every 15 minutes on the 15 and while I currently only have 16 or so clients calling every 15 min on the 15, I'm wondering about the following:
If two clients call at close enough to the same time, will one client's connection attempt fail?
How I can figure out how many client connections my server can accommodate at the same time?
How can I monitor how much memory my server is using?
Also, is there an article you can point me toward that discusses the best way to implement this kind of a server? I mean can I have multiple instances of the server listening on the same port? Would that even help?
I am using Bluepill to monitor my server daemons.
1 and 2
The answer is no, two clients connecting close to each other will not make the connection fail (however multiple clients connecting may fail, see below).
The reason is the operating system has a default so called listening queue built into all server sockets. So even if you are not calling accept fast enough in your program, the OS will still keep buffering incoming connections for you. It will buffer these connections for as long as the listening queue does not get filled.
Now what is the size of this queue then?
In most cases the default size typically used is 5. The size is set after you create the socket and you call listen on this socket (see man page for listen here).
For Ruby TCPSocket automatically calls listen for you, and if you look at the C-source code for TCPSocket you will find that it indeed sets the size to 5:
https://github.com/ruby/ruby/blob/trunk/ext/socket/ipsocket.c#L108
SOMAXCONN is defined as 5 here:
https://github.com/ruby/ruby/blob/trunk/ext/socket/mkconstants.rb#L693
Now what happens if you don't call accept fast enough and the queue gets filled?
The answer is found in the man page of listen:
The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.
In your code however there is one problem which can make the queue fill up if more than 5 clients try to connect at the same time: you're calling #thr.join at the end of the loop.
What effectively happens when you do this is that your server will not accept any new incoming connections until all your stuff inside your accept-thread has finished executing.
So if the database stuff and the other things you are doing inside the accept-thread takes a long time, the listening queue may fill up in the meantime. It depends on how long your processing takes, and how many clients could potentially be connecting at the exact same time.
3
You didn't say which platform you are running on, but on linux/osx the easiest way is to just run top in your console. For more advanced memory monitoring options you might want to check these out:
ruby/ruby on rails memory leak detection
track application memory usage on heroku

when castle activerecord closes a connection

I started using nhibernate the same time I started using castle activerecord so I have those mixed up questions sometimes
I was wondering when activerecord (or nhibernate) closes a connection when the following code runs:
Dim entity = TABLE_Y.TryFind(id)
if not entity is nothing then
'long running process here
response.redirect("...")
end if
I'm asking this because this long running process takes more than one hour to finish and whenever the code redirects to another page I get an ORA-03135 (connection lost contact) telling me the connection was lost, this other page has the following active record query:
Dim entity = TABLE_X.FindAll(Order.Desc(...), _
Expression.Eq(...) And _
Expression.Eq(...)).FirstOrDefault
which then returns the ora-03135
so I was thinking if couldn't be any connection from activerecord that didn't close before the long running process
this long running process is literally another process started by the application which wait for it to end before redirecting to another page, so even if the other process uses active records it doesn't use the same connection string or whatsoever
it's funny because I'm starting a new query on a completely different table, is activerecord trying to reuse an existing connection that timed out? I tried to add "Pooling=False" and "Validate Connection=true" with no luck
thanks in advance
The connection will be closed when the session is disposed of, where this happens depends on your application. If you're using the module that comes with ActiveRecord then it will happen when the Application.EndRequest event fires (ie. at the end of your request), if you aren't, then you need to see where a SessionScope or TransactionScope is created and disposed (the dispose is where the connection is closed).
If you want to start a long running task and redirect before it's complete you will need to start it in another thread (eg. using ThreadPool or Tasks). You will also need to configure ActiveRecord to use the HybridWebThreadScopeInfo so that it will store the session in a thread local when the HttpContext is unavailable (which is what will happen in your background thread).
<activerecord threadinfotype="Castle.ActiveRecord.Framework.Scopes.HybridWebThreadScopeInfo, Castle.ActiveRecord">
Then in your task, wrap it in a TransactionScope or SessionScope (I prefer the former):
using(var trans = new TransactionScope()) {
// do your stuff here...
trans.VoteCommit();
}

Does BoneCP (or any other pool) close connection's statements when connection is returned to pool?

Does BoneCP (or any other pool) close connection's statements when connection is returned to pool? As I understand, it does not call actual connection's close method, so there is no automatic statement closing. So, does it close statements in any other way or do I need to close them manually?
The JDBC spec is very unclear on what should happen under normal connection close so, irrespective of the pool you use, you should always make sure to close off the statements manually. Consider what would happen to your application if you opt to switch to a different pool in the future that does not do what you expect it to do for you.
As regards BoneCP, the answer is no, it will not close off your statements for you though it can be configured to close off your connections if you forget. This is for performance reasons since some JDBC drivers will close off any still active statements internally if you close off the connection.
However, BoneCP will close off any cached statements if you have statements caching enabled.
EDIT: As of v0.8.0, support has been added to close off unclosed statements (+ print out stack trace of location where statement was opened if you want).
BoneCP (0.8.0 -RC3), there are 2 possible results,
close off with some configuration for non-cached statement only
non-close off no matter how you configure it for cached statement even you invoke the statement.close() explicitly.
There is a StatementCache class to cache the preparedStatement & callableStatement. The default is disabled. You need call BoneCPConfig.setStatementsCacheSize() with the >0 parameter to enable it. After enable the cache,
1 BoneCP.Statement.Close() will bypass the underlying statement close if it is cached.
public void close() throws SQLException {
this.connectionHandle.untrackStatement(this);
this.logicallyClosed.set(true);
if (this.logStatementsEnabled){
this.logParams.clear();
this.batchSQL = new StringBuilder();
}
if (this.cache == null || !this.inCache){ // no cache = throw it away right now
this.internalStatement.close();
}
}
2 BoneCP.Connection.close()
Will just simply clear the cache through the function "clearStatementCaches()"
The good news is MYSQL JDBC driver, Connector/J, will close all the opened statements when you close the connection through the function "closeAllOpenStatements()"

VB6 ADO Connection Pooling

We have a bunch of VB6 apps at our company. We are trying to debug a random SQL timeout error and did a trace with SQL Server Profiler on the Audit Login event. We noticed that the connections were coming in as nonpooled. We use the SQLOLEDB provider with SQL Server 2000 & 2005. I searched the internet and everything I come across says that connections are pooled by default in the SQLOLEDB provider, but we are not seeing this. Below is the code we use to connect to the database. We really need to have these connections pooled because we think this may be the problem with our random timeout error. Could any one shine some light on why connection pooling isn't working and any way to make it work? Thanks.
Dim cnn As New ADODB.Connection
cnn.ConnectionString = "Provider=SQLOLEDB;Data Source=xxx;Catalog=xxx;User ID=xxx Password=xxx;"
Call cnn.Open
Dim cmd As New ADODB.Command
Set cmd.ActiveConnection = cnn
cmd.CommandText = "SELECT * FROM [Table]"
Dim rs As New ADODB.RecordSet
Call rs.Open(cmd, , adOpenStatic, adLockOptimistic)
While Not rs.eof
'Do stuff
Call rs.MoveNext
Wend
'Close and Dispose connection here
Disposing the connection on every call could prevent pooling
...at least one instance of a Connection
object instantiated for each unique
user—at all times. Otherwise, the pool
will be destroyed when the last
Connection object for that string is
closed.
http://msdn.microsoft.com/en-us/library/ms810829.aspx
I messed around and opened a connection at app startup and kept it open through the entire time the app was running. Connection pooling did start after the second opened and closed connection.
You mentioned that you were trying to track down a random timeout problem. I've had the same, generally when I was doing a SELECT that returned a lot of rows. Two things:
Cnn.CursorLocation=ADODB.adUseServer
(The other option is adUseClient) - I believe adUseServer gave me faster queries, which reduced the likelihood of timeouts. You do this before you open the connection, I believe.
Cnn.CommandTimeout=0
Also before the open(), tells it that you want an infinite timeout. I think the default timeout is something like 30s, which was way too short for some queries. The CommandTimeout will be used for Recordset queries. If you use a Command object, it has it's own CommandTimeout member, which doesn't appear to inherit from the Connection (ie, I set it before I Execute a command).
Sorry if the syntax isn't quite right, I'm cutting from some C++ code.

Resources