Description:
The falcon_max_transaction_backlog appears to have no effect. When set to 1, SELECT * FROM
INFORMATION_SCHEMA.FALCON_TRANSACTIONS continues to show more than 1 transaction in state
= 'active'

How to repeat:
1. SET GLOBAL falcon_max_transaction_backlog = 1;
2. Run some transactional workload;
3. Observe no serialization, observe that I_S continues to show multiple active
transactions.

The falcon_max_transaction_backlog is not meant to limit concurrency on teh front end.  It
is ment to limit the throughput int the middle where transactions that commit are
processed by the gopher threads.  When it was added, there was only on gopher thread and
it was intended to limit the front end from over working the middle so that the lists of
deferred indexes become to long and everything starts to slow down.  

Now, however, we have a herd of gophers which keep up with the client threads very well.

In fact I would recommend changing this bug to "falcon_max_transaction_backlog is not
needed."

Waiting for confirmation from Jim Starkey.

Have we come to any conclusion on this?

falcon_max_transaction_backlog was a debugging aid for a 
problem that has been corrected by adding gopher threads.
It should be removed.

Then I'll go ahead and close it with the hopes that we can reopen it if needed. If there
are now objections within the time it takes me to prepare and eat my Norwegian
fish-dinner, I will close it.

Of course I dont't mean close it... I mean that I'll remove it... Too late in the
afternoon, I guess. Maybe I should postpone removing it until the morning :)

I would like to suggest that you do not delete the actual limit of serial log transactions
that can be committed and not yet handled by the gopher thread(s) and that you make it a
hard coded value.  I would recommend 1000 instead of the current default of 150.  That is
a very conservative amount according to Jim Starkey who believes this to be an acceptable
alternative to having no limit at all.  Enforcing this limit would keep the Falcon engine
from 'burying itself'.  If it gets that far behind, something is really wrong, and it is
probably best to refuse new work until it is resolved.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/48955

2723 lars-erik.bjork@sun.com	2008-07-03
      bug#36991 falcon_max_transaction_backlog has no effect
      
      I have changed the maxTransactionBacklog to 1000 and have made the value
unconfigurable.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/48956

2723 lars-erik.bjork@sun.com	2008-07-03
      bug#36991 falcon_max_transaction_backlog has no effect
      
      I have changed the maxTransactionBacklog to 1000 and have made the value
      unconfigurable.

This fix is in version 6.0.6

A note has been added to the 6.0.6 changelog: 

The falcon_max_transaction_backlog has been removed. The option was originally introduced
to ensure that the backlog of transactions did not exceed a certain level with the gopher
thread. FALCON now uses multiple gopher threads. The transaction backlog is handled
internally by FALCON