EmptyInterceptor

emn · **Joined:** Wed May 06, 2009 4:38 pm **Posts:** 12

Hi,

I have overriden the behaviour of the EmptyInterceptor in Hibernate to add ThreadLocal property value to the JDBC statements executed by Hibernate (a database switch based on user connected) :

Code:

public String onPrepareStatement(String sql)
    {
   String onPrepareStatement = super.onPrepareStatement(sql);
   if (test)
   {
       onPrepareStatement = TEST_DB_NAME_PATTERN.matcher(onPrepareStatement).replaceAll("");
   }
   else
   {
       String database = null;

       if (TenantManager.getTenantMap() != null)
       {
      database = TenantManager.getTenantMap().get(UserContextHolder.getTenant());
       }

       if (database == null)
       {
      database = defaultDB;
       }

       onPrepareStatement = DB_NAME_PATTERN.matcher(onPrepareStatement).replaceAll(database);
   }
   return onPrepareStatement;
    }

This works fine for Hibernate. It changes the target of the SQL calls executed by Hibernate, just before their execution.

Now when the data is indexed by Hibernate Search, the target database (the catalog or schema) is not set. I understand that Hibernate search doesn't execute its indexing by performing JDBC calls. Instead it is delegated to Lucene.

How should I implement the same database switch in Hibernate Search ? Which component should I use to change the indexing database target just before data is indexed ?

Best regards,
Eric

sanne.grinovero · **Posted:** Wed Mar 17, 2010 5:37 pm

Hi,
indexes are not stored in a database usually but in a Directory; a Directory is an abstraction to many kinds of stores, the most common is filesystem.

Have a look into sharding, you can implement a custom sharding strategy to achieve this. Or you use a simple filter, and store all documents in the same shared index.

http://www.jboss.org/hibernate/subprojects/search/docs.html

emn · **Joined:** Wed May 06, 2009 4:38 pm **Posts:** 12

Thanks for your answer.

I have looked at Sharding feature. As I understand it by implementing IndexShardingStrategy I can define the way a shard is selected to index data. Since the indexing is performed asynchronously, I guess it is not performed by the thread processing the user request. The ThreadLocal variable can't be used to get the discriminant value, isn't it ?

I also need to add dynamically new indexing Directory when a new customer is registered. From what I see in the documentation, sharding definition is static (in property file). Is there a way to add a shard dynamically, or does it need to reload the SessionFactory ?

What is the second technique you mention ("Simple Filter") ? Can you give me a pointer to use this ?

Best regards,
Eric

sanne.grinovero · **Posted:** Wed Mar 17, 2010 7:16 pm

Quote:

The ThreadLocal variable can't be used to get the discriminant value, isn't it ?

Not at indexing time, but if you can understand the right shard from some information in the Document you're set. The Document is built by the same thread as user transaction, so at that moment you could add some extra information.

Quote:

I also need to add dynamically new indexing Directory when a new customer is registered. From what I see in the documentation, sharding definition is static (in property file). Is there a way to add a shard dynamically, or does it need to reload the SessionFactory ?

That's planned for future, currently you'll need to reload the SessionFactory.

Quote:

What is the second technique you mention ("Simple Filter") ? Can you give me a pointer to use this ?

Just look into "filters" on the reference.

emn · **Joined:** Wed May 06, 2009 4:38 pm **Posts:** 12

Thanks for your advise. I think filtering (a QueryWrapperFilter) fills the bill.

The sharding technique is nice, but as I have read in the documentation the number of shards should not be to high to preserve performance. And this would be likely to happen since the number of application customer may grow (if we are successful in our project).

Best regards,
Eric