I am reporting back to this group as a follow up to my posts
yesterday. Over the past several weeks I have been trying to track
down issues related to connections to my database that were not
closing and leaving data uncommitted in some cases. My original post
to this group was:

http://tech.groups.yahoo.com/group/firebird-support/message/95395

At the time of this post, I did not have issues with connections not
closing, but did have issue with the firebird.log growing to hundreds
of megabytes in size. So, I switched my connection string to use the
XNET protocol. However, I was experiencing further issues, I guess
due to load, and switched to TCP. Switching to TCP is where I began
to witness these "hung" connections. I spent countless hours
debugging and stepping through code and reviewing the monitoring
tables. But, the connections which "hung" were completely random.
Meaning, an area of my applicataion which hung before, would not hang
the next time, but a different area would. Was driving me completely
nuts. So, I switched back to the XNET protocol and then posted this
message:

http://tech.groups.yahoo.com/group/firebird-support/message/98052

So, after being convinced yet again, that XNET is not capable of
handling the load, I switched back to TCP, again. Then posted this
messsage:

http://tech.groups.yahoo.com/group/firebird-support/message/98092

After exhausting every resource I could think of and ready to throw
my hands in the air, I switch back to WNET. As expected, everything
about the system runs perfectly with this protocol. All connections
close properly, no lost data, etc. But, the firebird.log file grows
like a weed. So, I added a scheduled process to delete the log file
nightly.

The server this Firebird installation is running on is a Hosted /
Managed server @ Rackspace. I have had Rackspace personnel turn this
server upside down trying to find hardware issues. All components
pass all tests with flying colors.

I really don't have any other useful information for further research
into the TCP protocol, but there is definitely something going on in
2.1.1 (and possibly earlier versions) which is resulting in the
behavior described above. Vlad has already inidicated that a fix is
coming for XNET. But, if I end up in a situation where I need to
move my database to a different server, I would really like to use
TCP instead of WNET.