We have an application where we are using Hibernate Search 4.1 for implementing lucene based search. We are using both incremental indexing and manual indexing(scheduled) and both are using the same lucene directory.

This design has a flaw when both indexing works parallel, some of the indexes get lost if there is write lock on any of the indexes.
Also the same problem will arise in clustered environment as lucene doesn't allow multiple writers on same lucene index.

There is standard solution(Master-slave setup) documented in the Hibernate search document. I am just evaluating the other solutions also. For example, Can i also use the customized backend to redirect all the lucene updates to QueueManager and then allowing one of the server to consume the lucene updates and write to the lucene indexes. In this case, Only one of the instances will have write access to indexes and other instances will only be reading indexes.

Hi that's correct, you should never allow two different instances to write on the same index because of the locking requirements.

Configuring one of your servers as master is the appropriate solution.

You mentioned "multiple server instances"; do you mean on physically separate servers? Keep in mind there are problems with sharing a read/write index over network shares: that's another good reason to use the master/slave architecture as explained in the reference documentation.