Disposing a session does not deter caller to keep using it

[Frank Quednau]

The following code:

var s1 = Store.OpenSession();

s1.Store(new Thing() { Id = "1" });

s1.Dispose();

s1.Store(new Thing() { Id = "2" });

works as if I'd never have called dispose. And yes, you can even do that:

var s1 = Store.OpenSession();

s1.Store(new Thing() { Id = "1" });

s1.Dispose();

s1.SaveChanges();

Granted, we do have an issue in our code in that we should never have tried to use a disposed session but you would expect a disposable object to throw an ObjectDisposedException when you attempt to use it.

As a related question, does session.Dispose() actually do anything?

[Mircea Chirea]

AFAIK, no. Disposing the session at the moment doesn't do anything.

[Mircea Chirea]

That doesn't mean you shouldn't dispose sessions. You never know when it MIGHT do something.

[Kijana Woodard]

This is standard .net

On May 22, 2013 12:45 PM, "Mircea Chirea" <chirea...@gmail.com> wrote:

That doesn't mean you shouldn't dispose sessions. You never know when it MIGHT do something.

--
You received this message because you are subscribed to the Google Groups "ravendb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Frank Quednau]

What is? Not doing anything on Dispose() ?

[Chris Marisic]

I think disposing the session empties the cache that's in the session, I'm not 100% certain however.

[Mircea Chirea]

Dispose does nothing:

https://github.com/ravendb/ravendb/blob/master/Raven.Client.Lightweight/Document/InMemoryDocumentSessionOperations.cs#L981

Neither DocumentSession, AsyncDocumentSession nor ShardedDocumentSession override that.

As for the cache, that seems to be disposed when SaveChanges is called.

[Kijana Woodard]

Yeah. Nothing about IDispoable specifies the _behavior_ of the object after calling Dispose().

The semantics of IDisposable is that you've told the object that your code no longer needs it. That gives the object a chance to "clean up internal resources". That doesn't guarantee that some behavior will stop working or that any memory will be released or anything else. It also doesn't say that anything will continue to work. The semantics imply that you shouldn't rely on behavior after calling dispose. 

Just because raven client does nothing differently today doesn't mean that vNext won't start doing something.

Hell, with .net even setting an object to null doesn't doesn't guarantee memory cleanup or a halt to behavior assuming some internal state or ongoing processing.

[Chris Marisic]

Ah, it's save changes that does it.

I do know once you call SaveChanges() that puts the session into an undefined state, as a rule you're not supposed to call savechanges more than once per session, but it won't stop you from it.

[Itamar Syn-Hershko]

That statement is not true, Chris. All SaveChanges does is move the in-memory buffers to a request object and sends it to RavenDB, cleaning those buffers and readying them for accepting new work.

--

[Kijana Woodard]

Thanks for clarifying that Itamar. I've called SaveChanges several times when using sequential ids that are generated by the server and then attaching those ids to other docs. I try to avoid this scenario however.

[Oren Eini (Ayende Rahien)]

Nope, SaveChanges is a well defined state.
And you are absolutely fine to call SaveChanges more than once.

On Wed, May 22, 2013 at 10:13 PM, Chris Marisic <ch...@marisic.com> wrote:

--

[Oren Eini (Ayende Rahien)]

What I think you are thinking here is the state that you get into if SaveChanges threw an exception

On Wed, May 22, 2013 at 10:13 PM, Chris Marisic <ch...@marisic.com> wrote:

--