Hamed Madani, I am not sure what you are looking at. HTable has no reference to any HTablePool instance, so calling HTable.close does not return it to the pool. There is an internal pool of worker threads handled in HTable.close() but that is unrelated.
Devin Bayer, I see what you are saying - and of course we need to hold on to the table instances - either using HTablePool or as Thrift 1 does with our own list (which you do of sorts).
Your patch does change the behaviour so that when a scanner is opened, the HTable instance is not returned to the pool, but only when you close the scanner.
The first issue you are describing is that when you return the table, you might run into the issue that the table is reused although they are not thread safe. That should not be an issue since you are not using the table anymore, but a scanner instance. I think the second issue you describe is the problem, i.e. when a table is closed, the underlying connection is closed possibly, and therefore leaves the scanner dangling.
I need to look into 0.94, 0.95 and trunk/0.98 to see what the status (as you and Hamed touch upon above). If we decide to hang on, we could wrap this into
HBASE-3852 which creates a Scanner wrapper, holding a last-used time and the actual result scanner. We could easily add the table instance there and hold on to it in one map. Same thing as yours, just a merge.