On 2013-11-29 10:36 AM, Etienne Cimon wrote:
On 2013-11-29 2:20 AM, Sönke Ludwig wrote:
version (Havevibed) TCPConnection stream;
That's amazing, thanks ! Also, I couldn't find stream.stream.read so I
assumed I'd have to read as ubyte[] all the way. Should be very simple
there then!On another subject, I was looking into ConnectionPool and it seems like
(for any reason) an unresponsive database (with maybe a bad timeout or
trapped in locking) would let connections accumulate until size_t.max
(one for every visitor). Wouldn't a 2^63 of these objects clog the RAM
and make the application crash? It would probably be a good idea to
limit this in an options associative array as to keep it at a consistent
value with the database's max connections. Something of the sorts:struct PoolOptions {
size_t m_maxConnections;} m_poolOptions;
:32 this(Connection delegate() connection_factory, PoolOptions options =
new PoolOptions(100)):39 sizet cidx = mpoolOptions.m_maxConnections;
:44 if( cidx <= mpoolOptions.mmaxConnections ){
I would image it to be wise to put lockConnection in a yielded loop
where a connection is eventually returned. What do you think?
Here's the Postgresql connector for vibe.d in my github fork case anyone
is interested, it's being tested to be pulled later into the main project.
https://github.com/etcimon/ddb
It's tested on windows dmd x86_64 with postgresql 9.3.1. but I didn't
add ConnectionPool support yet
e.g.
auto conn = new PGConnection;
conn.open([
"host" : "localhost",
"database" : "postgres",
"user" : "postgres",
"password" : ""
]);
scope(exit) conn.close;
auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery;
try
{
foreach (row; result)
{
writeln(row["typname"], ", ", row[1]);
}
}
finally
{
result.close;
}