In a brainstorming session we ended up discussing the case in which you would aggressively use FullTextSession#flushToIndexes(), in combination with a JMS backend which was configured to only send messages on commit of a global transaction.

The flushToIndexes() javadoc don't currently clarify this strictly, but I've always assumed that the name would suggest it to flush to the index - and it should be generally understood that an index is not transactional.

So I think the idea has merits as it's nice to save memory and delegate the indexing work to the messaging queue early on, but we should:

• avoid twisting the meaning of the flushToIndexes() method

• maintain consistency across backends (others are unable to run transactions)

So rather than having users apply this interesting trick which depends on various configuration factors, it would be interesting to explore if we should auto-flush index operations more aggressively on capable backends.
One could also avoid issuing warnings on auto-flush events.

(This is all assuming the backend works in the same thread of the application, or is able to look up the right transaction in some other way as we're not guaranteeing this today. We don't have any transactions-ready backend currently available OOB either, so I'm really assuming that would be implemented first.)