The crux of my question is when do you need to clear the indexing queue without having to clear the session?

I see this method as part of the explicit indexing API where I would be able to clear the entities scheduled to be indexed via FullTextSession.index(). I am also not sure when exactly I would use it. I guess one could image an exception during indexing where as part of the exception cleanup one wants to clear the already scheduled work.

The other question is around event based indexing and semantics around Session.save() and Session.clear() (might belong to HSEARCH-1270). Assuming this code:

	@Test
	public void testSessionClearWithSave() throws Exception {
		Session session = openSession();
		Transaction tx = session.beginTransaction();

  		Foo foo1 = new Foo();
 		session.save( foo1 );

		 session.clear();

 		Foo foo2 = new Foo();
		session.save( foo2 );

		tx.commit();
                session.close();
	}

What is the result. Which Foo}}s end up in the database? Only {{foo2} or {{foo1 and foo2. I was kind of assuming the former, but that is not the case. AFAICT both instances are persisted. Am I using clear() the wrong way or are the semantics different?

If the behaviour is expected, then I argue that indexing is correct, since both instances get indexed.

The other question is whether there is a semantic difference between Session.save and Session.persist when it comes to lifecycle events?