Hello, my name is Aleksander M. Stensby.
Last week I posted a question (obviously in the wrong place) on the hibernate-dev mailing list.

Mr. Emmanuel Bernard was kind to direct me here, and to also answer part of my question.



Problem is, we make use of Spring's AbstractRoutingDataSource (as proposed by Interface21 blogger Mark Fisher). Mainly, we do this because from what we have read, multiple session factories does not scale with regard to being resource intensive etc.

So, it boils down to the following:
We have multiple databases(schemas) with the exact same design (domain model) but obviously different content.
We have one session factory, mapped to one datasource, which in turn is an implementation of an AbstractRoutingDataSource. This again maps several datasources, each representing the different databases. So, they get their connection.url from a hibernate.properties file. Nice, it works.

But, here comes the challenge and my question:
We would like to migrate from pure lucene to hibernate-search. We want to make use of hibernate events and auto-indexing. Only problem is, since we do not have X number of session factories, how can we map the different "indexBase" paths in the same way as we did with datasources?


Ideally (in my dream world), I would just add the path the same place we differentiate between db connection url's.. (e.g. in the datasource configuration).

Is there any way to accomplish this, or do we have to make use of multiple sessionfactories to do so?

Thanks for any answers, and please let me know if this was not clear in any way :)

Hibernate version: 3.2.4.sp1
Name and version of the database you are using: MySQL 5.0

Hummm,
I am not sure how you use your switch, but you have to understand that such a choice breaks the second level cache.

Did you try multiple SF before declaring it as too resource intensive? It completely depends on the mapping, on the application constraint and on how many SFs you expect.

Anyway, regardless of the initial decision. You can use Hibernate Search in such an environment but you will probably have to write your own FSDirectoryProvider provider (just change a few lines from the original one) so that it reads the directory as ${indexBase}/CustomerContextHolder.getCustomerType()

This would work. You probably also need to switch to the non-shared reader strategy http://www.hibernate.org/hib_docs/search/reference/en/html_single/#configuration-reader-strategy.
The shared strategy is robust enough to support your use case but your routing strategy defeats the whole caching mechanism, not-shared would be more efficient. (Alternatively you could also fork the shared strategy implementation to be aware of the customerType as well, that's probably more work though).

Thanks again Emanuel!
I see your point on the cache, and I think that ideally we should have one large DB and Index (and possibly/maybe) shard it in some way, instead of operating with indentical db's with unique Ids... (e.g. change to a global unique ID,... the only issue is the scaling issue which... partitioning is not straightforward in our environment, but that is not a search / shard issue, so I will not bother you guys with that:)

Thanks