Add a "maximum active sessions" value to bound how many hazard reference
array slots we have to walk during page evictions.   Ref #186.
We no longer copy the hazard reference array, which means there's no
reason for it to be maintained outside of the WT_SESSION_IMPL structure.
Move the hazard array into the WT_SESSION_IMPL structure, which makes
it easy to limit the hazard references being checked during eviction to
the set of active sessions.
Fix the barrier instruction for reading the session count.
Delete conn->sessions (rename conn->session_array to be conn->sessions),
but we now access the array of session handles directly.  This means we
can no longer use the NULL vs. non-NULL test to know if a session handle
is active, add an active field that's non-zero if the session handle is
in use.

Stop shuffling the session array elements to keep them tightly packed:
allocate the lowest available slot we when allocating a new session,
decrement conn->session_cnt to the largest active slot when we close a
session.
The check to see if a page needs to be forcibly evicted is performed
within the serialization wrap-up function (and, if the page does need
to be forcibly evicted, the thread additionally schedules the eviction
and wakes the eviction server at the same time).  The problem is the
thread is holding a hazard reference: if the eviction server not only
wakes up attempts to evict the page before the thread releases the
hazard reference, the eviction attempt will fail, and the cycle will
repeat infinitely in the tcbench program, at least on pixiebob (the
problem won't occur if the eviction thread doesn't make significant
progress before the thread releases its hazard reference).  This is
unlikely to be an interesting performance problem, but it does affect
simple benchmarks where a single thread of control is inserting data as
quickly as possible, especially if the inserts are in ascending or
descending order.
    Instead of checking for forcible eviction when a page is modified,
this check when a hazard reference is being released.  Further, instead
of doing "size check, then schedule eviction, then wake eviction server,
then release hazard reference" do "size check, schedule eviction,
release hazard reference, wake eviction server"; this is required
because we can't release the hazard reference before scheduling the
eviction: if the hazard reference is the last one on the page, the page
might be gone before we schedule the eviction.
    This simplifies some things: we no longer call the routine to
schedule an eviction inside a serialization function (there's no
significance to that other than simplifying the world a bit).
    Finally, I removed the check for general cache size checking at
the same time as we were checking the individual page size.  We check
the general cache size every time we read a page into memory, I don't
see why that isn't going to be sufficient.
Merge branch 'develop' into hazard-page-check
Clarify why we publish the hazard reference clear in one case, but not in
another.
typo
If the __wt_evict_page_request() function is no longer called from
inside the serialization function, there's nothing to prevent threads
from racing when updating the request slot.  Add a spinlock around the
update: there's no need for anything tricky, this function should not
be called very often.
Merge branch 'develop' into max-session
Don't re-use conn->session_cnt -- it should work, but taking a copy is less
likely to introduce bugs in the future.
Typo: we took a copy of conn->session_cnt, but didn't use it.
The hazard array cannot be free'd or its reference cleared during
session close, we might race with the eviction thread reviewing it.
Change is to leave session hazard array references in place until
connection close, and to not clear the reference when closing the
session.
I didn't think through hazard reference memory management (thanks
valgrind!).  Don't allocate hazard reference memory if it's already
allocated; check the hazard reference memory of every session in the
array during connection close (not just the current count of active
sessions, as the active count may be less than the maximum count), and
discard hazard reference memory when discarding internal sessions.
The latter is kind of ugly, but I don't see a better solution.
Merge pull request #214 from wiredtiger/hazard-page-check

I'm merging this now.

That said, I like your suggestion of moving page requests into the session to avoid synchronizing around the request queue, and I still don't believe `WT_PUBLISH` makes any difference to clearing the hazard pointer (since the pthread operations involved in waking the eviction thread imply a full barrier), but this is an improvement on what we've got now, and we can continue to improve this code in future.

Michael.
Only try to forcibly evict modified pages.
refs #214

As well as an optimization for pathological cases where clean pages in memory are more than 20x larger than their on-disk representation, this also avoids forced eviction during special operations such as verify.
Merge pull request #212 from wiredtiger/max-session

closes #186
Have eviction process forced page eviction before file sync/close operations, to avoid the situation where a close frees a page scheduled for forced eviction.
refs #216
Add a cast to the Python API when setting a record number.
(Found in transaction testing, refs #183).
Merge branch 'develop' into feature/transactions

Conflicts:
	src/include/api.h
	src/session/session_api.c