-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
 Post subject: Dealing with multiple configuration files?
PostPosted: Mon Mar 10, 2008 4:54 am 
Newbie

Joined: Mon Mar 10, 2008 4:25 am
Posts: 4
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.

Quote:
To answer your question, you have different DBs, so different SessionFactory configurations (using the same mapping I imagine).
You will just have to change the following property in each hibernate.cfg.xml

hibernate.search.default.indexBase /usr/local/lucene/indexes/dbXX


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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 10, 2008 7:11 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
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).

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 21, 2008 3:05 am 
Newbie

Joined: Mon Mar 10, 2008 4:25 am
Posts: 4
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.