2

In the Grails 1.2.5 project that I am trying to troubleshoot, we use the Grails Searchable plugin .5.5.1.

The problem is that whenever we attempt to index large sets domain classes, Grails keeps throwing:

ERROR hibernate.AssertionFailure - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) org.hibernate.AssertionFailure: collection [domain-class] was not processed by flush()

But the domain classes involved have been mapped and used by hibernate without issues outside of the calls to searchable plugin.

The use of the searchable plugin goes as follows:

  1. Create a compass session with compass.openSession()
  2. Begin compass transaction: compassSession.beginTransaction()
  3. Then compassSession.create(result.get(0)) is called on an important unindexed domain class
  4. Finally compassTransaction.commit() is called to commit the transaction.
  5. Goto 2 and process next domain class

Between the 3 and 4th Domain class, an autoflush is triggered that throws the error.

Can anyone give me any hints about how to solve this problem?

Has anyone encountered this problem before?

I know that they had a systemic issue with this back in pre .5 versions of the searchable-plugin. Is it possible those issues weren't totally fixed?

Mark Rogers
  • 96,497
  • 18
  • 85
  • 138

1 Answers1

2

This article helped me understand it. You must be doing some Hibernate querying in a session that has dirty objects, and they get flush()-ed in the middle of modification.

Sometimes it's possible to move all the read-only queries outside of transaction, before any modification occurs, and do modifications in withTransaction{}.

Victor Sergienko
  • 13,115
  • 3
  • 57
  • 91
  • Thanks for the links. I actually solved the problem by reordering the calls so that all the result sets are retrieved first and then each result set is indexed. Before each result set was retrieved and indexed before the next result set. It's kind of ridiculous that reordering the calls fixes the problem, I would call this a bug. – Mark Rogers Mar 21 '11 at 15:13
  • I wouldn't call this a bug, as long as the calls are actually accessing same data concurrently. Moving read-only queries outside a critical section is a pattern of concurrent programming. – Victor Sergienko Mar 21 '11 at 16:34
  • @VictorSergienko: It's a bug because the order of the calls shouldn't work sometimes and not others, unless the cause is explicitly documented. If it doesn't work because of inconsistent behavior and there's no indication about why, then yeah that's a bug IMO. – Mark Rogers Mar 21 '11 at 17:19
  • @Mark, what you described is the way concurrent programming works (or doesn't work). – Victor Sergienko Mar 22 '11 at 09:59
  • @VictorSergienko: If you say so. I consider the flush effect to be **deferred execution** rather than **concurrent programming** because we are talking about a delay on execution rather than multi-threading/processing. – Mark Rogers Mar 22 '11 at 13:37
  • @MarkRogers: sure, you're correct. I am just choosing a more developed analogy. 1. IMO, flush happens no earlier then it's needed from the point of view of dirty objects - that is, at the very moment it's needed. Flushing earlier is undesired behavior. 2. Do i get you right that it's not same code sometimes works, sometimes not - it's a reordered code that breaks? So the behavior is probably consistent :D 3. When you're *modifying* data, execution order definitely matters, right? `i++; i*=2;`. – Victor Sergienko Mar 22 '11 at 14:44
  • @VictorSergienko: Good points. "When you're modifying data, execution order definitely matters, right?" <- in many if not most cases, but if two pieces of data are not **coupled** in any way, such as in this case, then execution order should be, at least, theoretically irrelevant and therefore differing behavior should be well documented. – Mark Rogers Mar 22 '11 at 14:50
  • @MarkRogers: absolutely. I'm just afraid that the data **are** coupled in some internal way, either on the plugin or Hibernate level. It's the catch I was not aware of when hitting the subject error. – Victor Sergienko Mar 22 '11 at 17:03
  • @VictorSergienko: I hear yeah, sorry I can be a little too pedantic at times. – Mark Rogers Mar 22 '11 at 17:05