[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-152) Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero commented on HSEARCH-152: ----------------------------------------- actually we do write out of the lock; was one of the first changes I made to the backend before 3.1; we engage lock only for optimization work (all kinds: use demanded or optimization strategy triggered). The IndexWriting is going anyway to merge segments using the ConcurrentMergeScheduler, so having our thread lock the DP won't prevent the other thread (Lucene internal) from making changes fo FS. Not each add/remove will trigger this error even out of the lock; if a segment is missing it means it was merged by a background thread (pointing to the concurrentMergeScheduler again). Using the SnapshotDeletionPolicy would be a reliable way to ask the mergeScheduler to not delete files until we have finished replication; actually could make the whole DP locks useless. An alternative would be to lock all write operations, but also having to open and close the IndexWriter inside the lock to restart/stop all mergers each time; that would mean to revert all the work I did to improve performance. (that's why Search 3.0 likely didn't have this issue when you designed the FSMaster) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira