Hello, I think I found the reason for this error.
This call is not legal when using a thread bound session.
I just found this javadoc on org.hibernate.context.ThreadLocalSessionContext, which is the kind of Session I guess you're using?
Quote:
A {@link CurrentSessionContext} impl which scopes the notion of current
session by the current thread of execution. Unlike the JTA counterpart,
threads do not give us a nice hook to perform any type of cleanup making
it questionable for this impl to actually generate Session instances. In
the interest of usability, it was decided to have this default impl
actually generate a session upon first request and then clean it up
after the {@link org.hibernate.Transaction} associated with that session
is committed/rolled-back. In order for ensuring that happens, the sessions
generated here are unusable until after {@link Session#beginTransaction()}
has been called. If <tt>close()</tt> is called on a session managed by
this class, it will be automatically unbound.
So this explains that, when using threadbound Sessions, you should always wrap it all in transactions, this includes the call to Search.getFullTextSession(session).
You're not experiencing this same problem in 3.1.0 because in 3.1.1 there was added a check to verify that you are actually using transactions, as many other people where having trouble because they forgot to start transactions, even when making changes to entities.
So sorry for the trouble in 3.1.1, the correct solution is to use transactions!
Hardy, do you think we could improve on this? The ThreadLocalSessionContext could be less strict on this checks?