You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lucenenet.apache.org by "Kohlhepp, Justin W (Heritage Holdings (HHI))" <Ju...@thehartford.com> on 2012/06/01 19:33:15 UTC
Implementing IDisposable / finalizer pattern to avoid index lock issues
Hello,
I was surprised to notice that IndexWriter does not implement
IDisposable. It seems that the user is responsible for guaranteeing
that IndexWriter.Close is called and that IndexWriter itself does not do
this in a Dispose or destructor method. Do I have this understanding
correct? I wrote a wrapper around Lucene.NET for my application and was
forced to implement IDisposable / finalizer in order for index to unlock
correctly. Is this the expected pattern?
Thanks,
~ Justin
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Lingam, ChandraMohan J" <ch...@intel.com>.
Yes..should have mentioned 'depending on finalizer'.
Thx
Chandra
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, June 01, 2012 11:03 AM
To: <lu...@lucene.apache.org>
Subject: Re: Implementing IDisposable / finalizer pattern to avoid index lock issues
You meant "depending on the finalizer", not "depending on IDisposable"; IDisposable is called by the client and deterministic, finalizers are called by the runtime and not.
- Nick
On Jun 1, 2012, at 1:55 PM, "Lingam, ChandraMohan J" <ch...@intel.com> wrote:
> Depending on idispose to close index writer is a slippery slope as it is unpredictable when garabage collector will kick in.
>
> In the worst case, you may not be able to add/remove documents to the index if some uncollected object is holding the lock on the index. Cleaner approach is to simply close once the maintenance is completed.
>
> -----Original Message-----
> From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
> Sent: Friday, June 01, 2012 10:48 AM
> To: lucene-net-user@lucene.apache.org
> Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
>
> Hmm...well my implementation is too layered to allow for a try/catch to correctly ensure that IndexWriter.Close is called, so I'm pretty much forced to use IDisposable / finalizer. I'm just surprised that IndexWriter itself doesn't do this work. Generally the expectation is that if a managed class manages an unmanaged resource such as a file on disk, that it cleans up after itself in a finalizer.
>
> Thanks for the response. It sounds like I'm not missing anything and this is just the way things are.
>
> ~ Justin
>
> -----Original Message-----
> From: Brian Sayatovic [mailto:bsayatovic@creditinfonet.com]
> Sent: Friday, June 01, 2012 1:44 PM
> To: lucene-net-user@lucene.apache.org
> Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
>
> I use a try/finally myself, with some extension methods to wrap it. My understanding is that IDisposable is wrought with trouble. My Lucene access is wrapped in an agent class, and my syntax ends up looking like DoWithAgent(agent => agent.UpdateIndex(foo));
>
> Brian Sayatovic
> Senior Software Architect
>
> 866-218-1003 toll-free ext. 8936
> 937-235-8936 office
> 4540 Honeywell Ct. Dayton, OH 45424
>
>
> This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
> If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
>
>
> -----Original Message-----
> From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
>
> I was surprised to notice that IndexWriter does not implement IDisposable. It seems that the user is responsible for guaranteeing that IndexWriter.Close is called and that IndexWriter itself does not do this in a Dispose or destructor method. Do I have this understanding correct? I wrote a wrapper around Lucene.NET for my application and was forced to implement IDisposable / finalizer in order for index to unlock correctly. Is this the expected pattern?
> ************************************************************
> This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
> ************************************************************
>
>
Re: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
You meant "depending on the finalizer", not "depending on IDisposable"; IDisposable is called by the client and deterministic, finalizers are called by the runtime and not.
- Nick
On Jun 1, 2012, at 1:55 PM, "Lingam, ChandraMohan J" <ch...@intel.com> wrote:
> Depending on idispose to close index writer is a slippery slope as it is unpredictable when garabage collector will kick in.
>
> In the worst case, you may not be able to add/remove documents to the index if some uncollected object is holding the lock on the index. Cleaner approach is to simply close once the maintenance is completed.
>
> -----Original Message-----
> From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
> Sent: Friday, June 01, 2012 10:48 AM
> To: lucene-net-user@lucene.apache.org
> Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
>
> Hmm...well my implementation is too layered to allow for a try/catch to correctly ensure that IndexWriter.Close is called, so I'm pretty much forced to use IDisposable / finalizer. I'm just surprised that IndexWriter itself doesn't do this work. Generally the expectation is that if a managed class manages an unmanaged resource such as a file on disk, that it cleans up after itself in a finalizer.
>
> Thanks for the response. It sounds like I'm not missing anything and this is just the way things are.
>
> ~ Justin
>
> -----Original Message-----
> From: Brian Sayatovic [mailto:bsayatovic@creditinfonet.com]
> Sent: Friday, June 01, 2012 1:44 PM
> To: lucene-net-user@lucene.apache.org
> Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
>
> I use a try/finally myself, with some extension methods to wrap it. My understanding is that IDisposable is wrought with trouble. My Lucene access is wrapped in an agent class, and my syntax ends up looking like DoWithAgent(agent => agent.UpdateIndex(foo));
>
> Brian Sayatovic
> Senior Software Architect
>
> 866-218-1003 toll-free ext. 8936
> 937-235-8936 office
> 4540 Honeywell Ct. Dayton, OH 45424
>
>
> This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
> If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
>
>
> -----Original Message-----
> From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
>
> I was surprised to notice that IndexWriter does not implement IDisposable. It seems that the user is responsible for guaranteeing that IndexWriter.Close is called and that IndexWriter itself does not do this in a Dispose or destructor method. Do I have this understanding correct? I wrote a wrapper around Lucene.NET for my application and was forced to implement IDisposable / finalizer in order for index to unlock correctly. Is this the expected pattern?
> ************************************************************
> This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
> ************************************************************
>
>
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Lingam, ChandraMohan J" <ch...@intel.com>.
Depending on idispose to close index writer is a slippery slope as it is unpredictable when garabage collector will kick in.
In the worst case, you may not be able to add/remove documents to the index if some uncollected object is holding the lock on the index. Cleaner approach is to simply close once the maintenance is completed.
-----Original Message-----
From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
Sent: Friday, June 01, 2012 10:48 AM
To: lucene-net-user@lucene.apache.org
Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
Hmm...well my implementation is too layered to allow for a try/catch to correctly ensure that IndexWriter.Close is called, so I'm pretty much forced to use IDisposable / finalizer. I'm just surprised that IndexWriter itself doesn't do this work. Generally the expectation is that if a managed class manages an unmanaged resource such as a file on disk, that it cleans up after itself in a finalizer.
Thanks for the response. It sounds like I'm not missing anything and this is just the way things are.
~ Justin
-----Original Message-----
From: Brian Sayatovic [mailto:bsayatovic@creditinfonet.com]
Sent: Friday, June 01, 2012 1:44 PM
To: lucene-net-user@lucene.apache.org
Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
I use a try/finally myself, with some extension methods to wrap it. My understanding is that IDisposable is wrought with trouble. My Lucene access is wrapped in an agent class, and my syntax ends up looking like DoWithAgent(agent => agent.UpdateIndex(foo));
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
-----Original Message-----
From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
I was surprised to notice that IndexWriter does not implement IDisposable. It seems that the user is responsible for guaranteeing that IndexWriter.Close is called and that IndexWriter itself does not do this in a Dispose or destructor method. Do I have this understanding correct? I wrote a wrapper around Lucene.NET for my application and was forced to implement IDisposable / finalizer in order for index to unlock correctly. Is this the expected pattern?
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
Posted by "Kohlhepp, Justin W (Heritage Holdings (HHI))" <Ju...@thehartford.com>.
Hmm...well my implementation is too layered to allow for a try/catch to
correctly ensure that IndexWriter.Close is called, so I'm pretty much
forced to use IDisposable / finalizer. I'm just surprised that
IndexWriter itself doesn't do this work. Generally the expectation is
that if a managed class manages an unmanaged resource such as a file on
disk, that it cleans up after itself in a finalizer.
Thanks for the response. It sounds like I'm not missing anything and
this is just the way things are.
~ Justin
-----Original Message-----
From: Brian Sayatovic [mailto:bsayatovic@creditinfonet.com]
Sent: Friday, June 01, 2012 1:44 PM
To: lucene-net-user@lucene.apache.org
Subject: RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
I use a try/finally myself, with some extension methods to wrap it. My
understanding is that IDisposable is wrought with trouble. My Lucene
access is wrapped in an agent class, and my syntax ends up looking like
DoWithAgent(agent => agent.UpdateIndex(foo));
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the
CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the
disclosure, copying, distribution or use of this information. All such
unauthorized actions are strictly prohibited. If you have received this
transmission in error, please notify the sender by e-mail and delete all
copies of this material from any computer.
-----Original Message-----
From: Kohlhepp, Justin W (Heritage Holdings (HHI))
[mailto:Justin.Kohlhepp@thehartford.com]
I was surprised to notice that IndexWriter does not implement
IDisposable. It seems that the user is responsible for guaranteeing
that IndexWriter.Close is called and that IndexWriter itself does not do
this in a Dispose or destructor method. Do I have this understanding
correct? I wrote a wrapper around Lucene.NET for my application and was
forced to implement IDisposable / finalizer in order for index to unlock
correctly. Is this the expected pattern?
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Justin,
I could be wrong here, but 2.9.4g is where the more .NET-like API is supposed to be exposed. It could very well be in there, if not, I'd say it's an oversight (assuming that IDisposable is implemented in other places).
The main branch is supposed to be a line-for-line port of the Java API, at least until enough steam can be obtained to maintain the current version of the Java API in .NET.
If you look in the archives for the dev mailing list, you'll see this topic come up more than a few times.
- Nick
-----Original Message-----
From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
Sent: Monday, June 04, 2012 7:42 AM
To: lucene-net-user@lucene.apache.org
Subject: RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
Nick,
I'm comfortable implementing dispose / finalizer pattern myself to make sure that the Lucene.NET IndexWriter is cleaned up. However, I don't understand why IndexWriter doesn't implement the dispose / finalizer pattern itself? Do you have an understanding of why this is? Or perhaps I should ask on the dev list?
Mostly I'm just curious. My implementation seems to be working fine so that is not an issue.
Thanks,
~ Justin
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, June 01, 2012 3:09 PM
To: <lu...@lucene.apache.org>
Subject: Re: Implementing IDisposable / finalizer pattern to avoid index lock issues
Brian,
The specific WCF case that you mention, yes there is specific cleanup that is required that IDisposable doesn't cover.
However, this is the case wherever you need *any* specialized cleanup.
This is more a fault of those that extended ICommunicationObject from IDisposable, not the other way around.
Long story short, unless you have *very* specialized situations around cleanup which requires specialized logic on the client, IDisposable is not the case.
Everything I've seen in Lucene.NET *doesn't* fall in this category and is suitable for having IDisposable implementations.
Granted, it's not as easy as slapping on the IDisposable interface and then having it call Close (note, a Close method with no return value and no parameters is a good indication that IDisposable is applicable here), the finalizers that *should* be implemented should *not* call IDisposable on references they hold, but it's not rocket science either.
- Nick
On Jun 1, 2012, at 2:59 PM, "Brian Sayatovic"
<bs...@creditinfonet.com> wrote:
> Crap! I went to look up the original information I read about the
using vs. try/finally and instead stumbled upon MSDN's own documentation or it confirming your statement:
http://msdn.microsoft.com/en-us/library/yh598w02(v=vs.90).aspx.
However, MSDN also documents, for example within their WCF pages, about the risks of using "using" if you're not fully aware:
http://msdn.microsoft.com/en-us/library/aa355056.aspx. There's also supposed internal discussions:
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/4cdc67e0-3069-4
d3b-b94f-27e2b8ff4429/. They're all around special clean-up scenarios and situations where your cleanup itself might fail but not be obvious in the syntax of the code. Those are all more prevalent with WCF, I suspect, than Lucene.NET.
>
>
> Brian Sayatovic
> Senior Software Architect
>
> 866-218-1003 toll-free ext. 8936
> 937-235-8936 office
> 4540 Honeywell Ct. Dayton, OH 45424
>
>
> This message may contain confidential/proprietary information from the
CINgroup or its subsidiaries.
> If you are not an intended recipient, please refrain from the
disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
>
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP]
[mailto:casperOne@caspershouse.com]
>
> 1) That is not true, using ultimately compiles down to a try/finally.
It's always called no matter how the block is exited.
>
> 2) This is a fault of the implementation. It is up to the implementer
to create a finalizer that disposes of resources that don't implement IDisposabe but need disposal (think raw handles). Regardless, try/finally doesn't improve the experience here; whatever method you use to have the caller deterministically release resources won't do any good if the finalizer isn't implemented correctly. Implementing IDisposable doesn't get you special consideration in the finalizer.
>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
RE: Implementing IDisposable / finalizer pattern to avoid index lock issues
Posted by "Kohlhepp, Justin W (Heritage Holdings (HHI))" <Ju...@thehartford.com>.
Nick,
I'm comfortable implementing dispose / finalizer pattern myself to make
sure that the Lucene.NET IndexWriter is cleaned up. However, I don't
understand why IndexWriter doesn't implement the dispose / finalizer
pattern itself? Do you have an understanding of why this is? Or
perhaps I should ask on the dev list?
Mostly I'm just curious. My implementation seems to be working fine so
that is not an issue.
Thanks,
~ Justin
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, June 01, 2012 3:09 PM
To: <lu...@lucene.apache.org>
Subject: Re: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Brian,
The specific WCF case that you mention, yes there is specific cleanup
that is required that IDisposable doesn't cover.
However, this is the case wherever you need *any* specialized cleanup.
This is more a fault of those that extended ICommunicationObject from
IDisposable, not the other way around.
Long story short, unless you have *very* specialized situations around
cleanup which requires specialized logic on the client, IDisposable is
not the case.
Everything I've seen in Lucene.NET *doesn't* fall in this category and
is suitable for having IDisposable implementations.
Granted, it's not as easy as slapping on the IDisposable interface and
then having it call Close (note, a Close method with no return value and
no parameters is a good indication that IDisposable is applicable here),
the finalizers that *should* be implemented should *not* call
IDisposable on references they hold, but it's not rocket science either.
- Nick
On Jun 1, 2012, at 2:59 PM, "Brian Sayatovic"
<bs...@creditinfonet.com> wrote:
> Crap! I went to look up the original information I read about the
using vs. try/finally and instead stumbled upon MSDN's own documentation
or it confirming your statement:
http://msdn.microsoft.com/en-us/library/yh598w02(v=vs.90).aspx.
However, MSDN also documents, for example within their WCF pages, about
the risks of using "using" if you're not fully aware:
http://msdn.microsoft.com/en-us/library/aa355056.aspx. There's also
supposed internal discussions:
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/4cdc67e0-3069-4
d3b-b94f-27e2b8ff4429/. They're all around special clean-up scenarios
and situations where your cleanup itself might fail but not be obvious
in the syntax of the code. Those are all more prevalent with WCF, I
suspect, than Lucene.NET.
>
>
> Brian Sayatovic
> Senior Software Architect
>
> 866-218-1003 toll-free ext. 8936
> 937-235-8936 office
> 4540 Honeywell Ct. Dayton, OH 45424
>
>
> This message may contain confidential/proprietary information from the
CINgroup or its subsidiaries.
> If you are not an intended recipient, please refrain from the
disclosure, copying, distribution or use of this information. All such
unauthorized actions are strictly prohibited. If you have received this
transmission in error, please notify the sender by e-mail and delete all
copies of this material from any computer.
>
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP]
[mailto:casperOne@caspershouse.com]
>
> 1) That is not true, using ultimately compiles down to a try/finally.
It's always called no matter how the block is exited.
>
> 2) This is a fault of the implementation. It is up to the implementer
to create a finalizer that disposes of resources that don't implement
IDisposabe but need disposal (think raw handles). Regardless,
try/finally doesn't improve the experience here; whatever method you use
to have the caller deterministically release resources won't do any good
if the finalizer isn't implemented correctly. Implementing IDisposable
doesn't get you special consideration in the finalizer.
>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by Brian Sayatovic <bs...@creditinfonet.com>.
Agreed! I misunderstood what I remembered. I applied it too broadly. I'm happily using Lucene.NET, and have not had any problems with cleanup, though I am using a more explicit pattern. I also log a lot of details and other stuff while I'm also closing the Lucene index. I have, after all, built upon Lucene.
Sorry for the confusion.
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
...
Long story short, unless you have *very* specialized situations around cleanup which requires specialized logic on the client, IDisposable is not the case.
Everything I've seen in Lucene.NET *doesn't* fall in this category and is suitable for having IDisposable implementations.
...
Re: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Brian,
The specific WCF case that you mention, yes there is specific cleanup that is required that IDisposable doesn't cover.
However, this is the case wherever you need *any* specialized cleanup. This is more a fault of those that extended ICommunicationObject from IDisposable, not the other way around.
Long story short, unless you have *very* specialized situations around cleanup which requires specialized logic on the client, IDisposable is not the case.
Everything I've seen in Lucene.NET *doesn't* fall in this category and is suitable for having IDisposable implementations.
Granted, it's not as easy as slapping on the IDisposable interface and then having it call Close (note, a Close method with no return value and no parameters is a good indication that IDisposable is applicable here), the finalizers that *should* be implemented should *not* call IDisposable on references they hold, but it's not rocket science either.
- Nick
On Jun 1, 2012, at 2:59 PM, "Brian Sayatovic" <bs...@creditinfonet.com> wrote:
> Crap! I went to look up the original information I read about the using vs. try/finally and instead stumbled upon MSDN's own documentation or it confirming your statement: http://msdn.microsoft.com/en-us/library/yh598w02(v=vs.90).aspx. However, MSDN also documents, for example within their WCF pages, about the risks of using "using" if you're not fully aware: http://msdn.microsoft.com/en-us/library/aa355056.aspx. There's also supposed internal discussions: http://social.msdn.microsoft.com/forums/en-US/wcf/thread/4cdc67e0-3069-4d3b-b94f-27e2b8ff4429/. They're all around special clean-up scenarios and situations where your cleanup itself might fail but not be obvious in the syntax of the code. Those are all more prevalent with WCF, I suspect, than Lucene.NET.
>
>
> Brian Sayatovic
> Senior Software Architect
>
> 866-218-1003 toll-free ext. 8936
> 937-235-8936 office
> 4540 Honeywell Ct. Dayton, OH 45424
>
>
> This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
> If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
>
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
>
> 1) That is not true, using ultimately compiles down to a try/finally. It's always called no matter how the block is exited.
>
> 2) This is a fault of the implementation. It is up to the implementer to create a finalizer that disposes of resources that don't implement IDisposabe but need disposal (think raw handles). Regardless, try/finally doesn't improve the experience here; whatever method you use to have the caller deterministically release resources won't do any good if the finalizer isn't implemented correctly. Implementing IDisposable doesn't get you special consideration in the finalizer.
>
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by Brian Sayatovic <bs...@creditinfonet.com>.
Crap! I went to look up the original information I read about the using vs. try/finally and instead stumbled upon MSDN's own documentation or it confirming your statement: http://msdn.microsoft.com/en-us/library/yh598w02(v=vs.90).aspx. However, MSDN also documents, for example within their WCF pages, about the risks of using "using" if you're not fully aware: http://msdn.microsoft.com/en-us/library/aa355056.aspx. There's also supposed internal discussions: http://social.msdn.microsoft.com/forums/en-US/wcf/thread/4cdc67e0-3069-4d3b-b94f-27e2b8ff4429/. They're all around special clean-up scenarios and situations where your cleanup itself might fail but not be obvious in the syntax of the code. Those are all more prevalent with WCF, I suspect, than Lucene.NET.
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
1) That is not true, using ultimately compiles down to a try/finally. It's always called no matter how the block is exited.
2) This is a fault of the implementation. It is up to the implementer to create a finalizer that disposes of resources that don't implement IDisposabe but need disposal (think raw handles). Regardless, try/finally doesn't improve the experience here; whatever method you use to have the caller deterministically release resources won't do any good if the finalizer isn't implemented correctly. Implementing IDisposable doesn't get you special consideration in the finalizer.
Re: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Brian,
1) That is not true, using ultimately compiles down to a try/finally. It's always called no matter how the block is exited.
2) This is a fault of the implementation. It is up to the implementer to create a finalizer that disposes of resources that don't implement IDisposabe but need disposal (think raw handles). Regardless, try/finally doesn't improve the experience here; whatever method you use to have the caller deterministically release resources won't do any good if the finalizer isn't implemented correctly. Implementing IDisposable doesn't get you special consideration in the finalizer.
- Nick
On Jun 1, 2012, at 2:42 PM, "Brian Sayatovic" <bs...@creditinfonet.com> wrote:
> The two problems I'm aware of (and, sorry, my memory is now foggy) are...
>
> 1. the "using" statement doesn't call your IDisposable's Dispose() method if an exception is thrown inside the using's block (hence why I use try/finally).
>
> 2. The IDisposable's method will be called by the finalizer if it hasn't been disposed, but not all finalizers are guaranteed to run when a VM is shutting down. That may not be a problem in this case (is it?), but in general, it's a hazard.
>
> Regards,
> Brian.
>
> Brian Sayatovic
> Senior Software Architect
>
> 866-218-1003 toll-free ext. 8936
> 937-235-8936 office
> 4540 Honeywell Ct. Dayton, OH 45424
>
>
> This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
> If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
>
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
>
> Would you clarify the statement "My understanding is IDisposable is wrought with trouble?"
>
> Perhaps the implementations are, or the usages are (the client doesn't call Dispose, but that same case exists with the current Close method).
>
> I ask because I've seen a number of discussions (on this list and off) around IDisposable that make unqualified statements like that which don't really point out any problems with IDisposable (or other .NET-specific features).
>
> - Nick
>
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by Brian Sayatovic <bs...@creditinfonet.com>.
The two problems I'm aware of (and, sorry, my memory is now foggy) are...
1. the "using" statement doesn't call your IDisposable's Dispose() method if an exception is thrown inside the using's block (hence why I use try/finally).
2. The IDisposable's method will be called by the finalizer if it hasn't been disposed, but not all finalizers are guaranteed to run when a VM is shutting down. That may not be a problem in this case (is it?), but in general, it's a hazard.
Regards,
Brian.
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Would you clarify the statement "My understanding is IDisposable is wrought with trouble?"
Perhaps the implementations are, or the usages are (the client doesn't call Dispose, but that same case exists with the current Close method).
I ask because I've seen a number of discussions (on this list and off) around IDisposable that make unqualified statements like that which don't really point out any problems with IDisposable (or other .NET-specific features).
- Nick
Re: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Would you clarify the statement "My understanding is IDisposable is wrought with trouble?"
Perhaps the implementations are, or the usages are (the client doesn't call Dispose, but that same case exists with the current Close method).
I ask because I've seen a number of discussions (on this list and off) around IDisposable that make unqualified statements like that which don't really point out any problems with IDisposable (or other .NET-specific features).
- Nick
On Jun 1, 2012, at 1:44 PM, "Brian Sayatovic" <bs...@creditinfonet.com>> wrote:
I use a try/finally myself, with some extension methods to wrap it. My understanding is that IDisposable is wrought with trouble. My Lucene access is wrapped in an agent class, and my syntax ends up looking like DoWithAgent(agent => agent.UpdateIndex(foo));
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
-----Original Message-----
From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
I was surprised to notice that IndexWriter does not implement IDisposable. It seems that the user is responsible for guaranteeing that IndexWriter.Close is called and that IndexWriter itself does not do this in a Dispose or destructor method. Do I have this understanding correct? I wrote a wrapper around Lucene.NET<http://Lucene.NET> for my application and was forced to implement IDisposable / finalizer in order for index to unlock correctly. Is this the expected pattern?
RE: Implementing IDisposable / finalizer pattern to avoid index
lock issues
Posted by Brian Sayatovic <bs...@creditinfonet.com>.
I use a try/finally myself, with some extension methods to wrap it. My understanding is that IDisposable is wrought with trouble. My Lucene access is wrapped in an agent class, and my syntax ends up looking like DoWithAgent(agent => agent.UpdateIndex(foo));
Brian Sayatovic
Senior Software Architect
866-218-1003 toll-free ext. 8936
937-235-8936 office
4540 Honeywell Ct. Dayton, OH 45424
This message may contain confidential/proprietary information from the CINgroup or its subsidiaries.
If you are not an intended recipient, please refrain from the disclosure, copying, distribution or use of this information. All such unauthorized actions are strictly prohibited. If you have received this transmission in error, please notify the sender by e-mail and delete all copies of this material from any computer.
-----Original Message-----
From: Kohlhepp, Justin W (Heritage Holdings (HHI)) [mailto:Justin.Kohlhepp@thehartford.com]
I was surprised to notice that IndexWriter does not implement IDisposable. It seems that the user is responsible for guaranteeing that IndexWriter.Close is called and that IndexWriter itself does not do this in a Dispose or destructor method. Do I have this understanding correct? I wrote a wrapper around Lucene.NET for my application and was forced to implement IDisposable / finalizer in order for index to unlock correctly. Is this the expected pattern?