The InterBase and Firebird Developer Magazine just released its first issue. It has some good stuff, like a warning not to mix and match the SQL and API savepoint instructions (pick one or the other). The savepoint article doesn’t mention IB 7.5.1’s SET TRANSACTION NO SAVEPOINT feature, but 7.5.1 is quite recent and may have come too late for the author to include. The feature allows you to specify that there should not be an implicit savepoint at the start of every SQL statement. This gives a performance advantage due to less overhead, but means that if a single statement fails you are required to rollback the whole transaction to maintain transactional integrity. It’s good to use when you have statements which affect a lot of data and must be executed atomically anyway.
The articles on embedded user authentication and global temporary tables are also good; these are under-documented features!
I disagree with some of what’s in the magazine, such as the blanket recommendation against hyper-threading on servers. I think it conflates too many factors, such as Win2000 vs. Server 2003 and IB 7.1 vs. IB 7.5. Also, I think the article on keepalive has a very serious omission by not mentioning the afd.sys memory leak which exists on Windows. That’s such a serious omission that if your IB server runs on Windows I’d recommend ignoring that article altogether. But overall the magazine was more than worth the time I spent reading it.
{ 7 } Comments
Thanks for comments, Craig!
I’d like to public some additions to the savepoints article where (among other things) the new IB 7.5.1 feature will be mentioned. I hope Alexey won’t mind including this stuff into the second issue.
> Also, I think the article on keepalive has a very serious
> omission by not mentioning the afd.sys memory leak which
> exists on Windows. That’s such a serious omission that if your IB
> server runs on Windows I’d recommend ignoring that article
> altogether.
IIRC, the memory leak happens on the client side, not on the server. So your recommendation is a bit strong.
Thank you for the comments, Craig.
All this stuff about an Adf.sys memory leak takes place only if you USE dummy packets. While I tried to imagine how does it works I discovered that only KEEPALIVE "kills dead connection" predictably and inevitably. And this article about KEEPALIVE is a result of a week-long expiriments on both KEEPALIVE and DUMMY_PACKETS. So I agree with your comment about adf.sys memory leak but disagree about your opinion on ignoring an article if your IB/FB server runs on Windows. To use KEEPALIVE is the key point of the article link to that you gave in your post. And I’ve been used KEEPALIVE (not DUMMY_PACKETS) successfully for a long time.
Dmitry:
"IIRC, the memory leak happens on the client side, not on the server."
No, this is incorrect. Please read the link in my post.
Vasily:
I didn’t say there was anything incorrect in your article; in fact it was quite interesting. But the afd.sys leak is IMHO an extremely serious problem; I just don’t think that discussion of sockets and dead clients is complete without it.
Was my recommendation too strong? Perhaps, unless people have DUMMY_PACKETS enabled on an affected version of Windows, in which case it isn’t strong enough.
Craig,
> No, this is incorrect. Please read the link in my post.
Unlike client, SuperServer always waits (asynchronously) for incoming packets. So whether it’s idle or under load, dummy packets will be received anyway. The leak is theoretically possible on ClassicServer, but it would happen only for a server executing single query for days which is very unlikely in practice.
Dmitry, I am not talking about a theoretical leak. I am talking about an *observed* leak, confirmed by IB R&D and multiple outsiders. If you won’t take my word, or Borland’s word, for it, try it for yourself with the described IB and OS version.
Post a Comment