That's surely right for web services or asp page requests. But I have some shared, stateless, local services requiring a readonly datacontext in the "Application State" (afaik this is it's name).
I can't recreate their instance on each request, since such a creation is expensive. But they can't have a state since the Application State should not grow too much. So also their components, such as the DataContext, must have not a state. So it must not keep track of objects. Note also that, since the services are in application, they could neither know when to create or dispose a "per request" DataContext. Giacomo On Fri, Apr 3, 2009 at 11:26 AM, Andrus <[email protected]> wrote: > I do'nt understand why you create global DataContext. > > If I understood properly good design practice is to have only short-living > Datacontext's, even in WinForms applications. > DataContext is created for single unit of work and must disposed after work > unit (ie. saving and invoice) is completed. > > Initially I tried to use Pascal object tracking + global Datacontext to > implement globale cache for Winforms application but failed since there is > no way to signal to Datacontext that some entity was changed. I created my > own cache implementation based on wrapper methods which create temporary > datacontext. > Nowadays I moved from Winforms to Silverlight. In this case I create DbLinq > Datacontext in every web service call and dispose it in this call. > > Andrus. > > ----- Original Message ----- > *From:* Giacomo Tesio <[email protected]> > *To:* [email protected] > *Sent:* Friday, April 03, 2009 12:13 PM > *Subject:* Re: ReadOnly DataContext (aka ObjectTrackingEnabled and > DeferredLoadingEnabled not implemented) > > This workaround could not be used in our environment. > > I was planning to create a readonly DataContext which stay alive. When data > will require to be saved a new copy of entities is sent to a service. > Other (read/write) DataContext will be created when required, but the > "single" readonly one should not be tracking object. > > > Giacomo > > On Fri, Apr 3, 2009 at 11:04 AM, Andrus <[email protected]> wrote: > >> I "fixed" this in the following way: I create new DataContext for every >> query which requires fresh data. >> >> Andrus. >> >> ----- Original Message ----- >> *From:* Giacomo Tesio <[email protected]> >> *To:* [email protected] >> *Sent:* Friday, April 03, 2009 11:58 AM >> *Subject:* Re: ReadOnly DataContext (aka ObjectTrackingEnabled and >> DeferredLoadingEnabled not implemented) >> >> Well, so by decison the DbLinq DataContext will always behave differently >> from the Microsoft one? >> >> >> http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.objecttrackingenabled.aspxin >> the remarks report that >> "Setting this property (*ObjectTrackingEnabled*) to false improves >> performance at retrieval time, because there are fewer items to track." >> >> I'm not sure about what items will be tracked when I actually say that >> they should not be tracked. >> >> But, performance a part, I'd like to be able to really disable the >> tracking. Also becouse I could actually prefer to not get the recently >> loaded customer since it could be changed in the db. >> >> >> Giacomo >> >> >> >> On Fri, Apr 3, 2009 at 9:58 AM, Pascal Craponne <[email protected]> wrote: >> >>> The identity tracking must not be stopped: within the same DataContext, >>> the same request done twice will return twice the same object. The >>> things to change are just the SubmitChange() and a few others. >>> >>> >>> On Fri, Apr 3, 2009 at 09:06, Giacomo Tesio <[email protected]> wrote: >>> >>>> I'll search... >>>> Actually, what is not so obvious is to *really* stop the identity >>>> tracking. >>>> >>>> This should produce faster DataContext during selects. >>>> >>>> >>>> DeferredLoading is actually a big miss. We should address it. >>>> We MUST document such a missing feature somewhere visible (since the >>>> Linq to Sql enable it by default!), or we become like Microsoft which often >>>> document only what works as expected (actually I did expect that it was >>>> working... fortunally it sould not be a problem for our design...). >>>> >>>> About the exception, we could throw a NotImplementedException when the >>>> user explicitly set true to DeferredLoadingEnabled, while not when he >>>> set it to false. >>>> We should also throw on each query when deferred loading is enabled (by >>>> default it is, according to the documentation), but I'm not sure it's >>>> acceptable... >>>> >>>> >>>> Anyway, I think that a list of missing features is every day more >>>> urgent! >>>> >>>> >>>> That said, what I should change to disable object tracking when * >>>> ObjectTrackingEnabled* is false? >>>> >>>> >>>> Giacomo >>>> >>>> >>>> >>>> >>>> On Fri, Apr 3, 2009 at 12:02 AM, Pascal Craponne <[email protected]>wrote: >>>> >>>>> Pong*. >>>>> >>>>> Well, apparently the changes are obvious :p Just check the value and >>>>> throw the exceptions when necessary. >>>>> >>>>> Regarding deffered loading, that's probably not as simple. We had >>>>> threads on it a long time ago, and I suggest you to search in the group >>>>> archives. >>>>> >>>>> * Answering "pong" to a "ping" is probably just a french joke. Sorry. >>>>> >>>>> On Thu, Apr 2, 2009 at 23:56, Giacomo Tesio <[email protected]> wrote: >>>>> >>>>>> Ping! :-D >>>>>> >>>>>> >>>>>> Giacomo >>>>>> >>>>>> >>>>>> On Wed, Apr 1, 2009 at 9:29 AM, Giacomo Tesio <[email protected]>wrote: >>>>>> >>>>>>> Ok >>>>>>> Here's the relevant documentation and the exceptions thrown. >>>>>>> Note that we should also consider the LoadOptions property (and the >>>>>>> DataLoadOption >>>>>>> class<http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.aspx> >>>>>>> ) >>>>>>> >>>>>>> What shoud be the working plan? >>>>>>> >>>>>>> >>>>>>> *bool ObjectTrackingEnabled* >>>>>>> Instructs the framework to track the original value and object >>>>>>> identity for this DataContext. >>>>>>> >>>>>>> Setting this property to false improves performance at retrieval >>>>>>> time, because there are fewer items to track. >>>>>>> >>>>>>> An exception is thrown: >>>>>>> >>>>>>> - If the property is set to false after a query has been >>>>>>> executed. [1] >>>>>>> For more information, see the Valid Modes section in >>>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx> >>>>>>> >>>>>>> >>>>>>> - >>>>>>> >>>>>>> If the property is set to false and >>>>>>> SubmitChanges<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.submitchanges.aspx>is >>>>>>> called. [2] >>>>>>> >>>>>>> *bool **DeferredLoadingEnabled * >>>>>>> Specifies whether to delay-load one-to-many or one-to-one >>>>>>> relationships. >>>>>>> >>>>>>> When false and the code accesses one of these relationships, null is >>>>>>> returned if the relationship is one-to-one, and an empty collection is >>>>>>> returned if it is one-to-many. The relationships can still be filled by >>>>>>> setting the >>>>>>> LoadOptions<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.loadoptions.aspx>property. >>>>>>> >>>>>>> Deferred loading requires object tracking. Only the following three >>>>>>> modes are valid: >>>>>>> >>>>>>> - >>>>>>> >>>>>>> >>>>>>> ObjectTrackingEnabled<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.objecttrackingenabled.aspx>= >>>>>>> false. DeferredLoadingEnabled is ignored and inferred to be false. >>>>>>> This behavior corresponds to a read-only >>>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx> >>>>>>> . >>>>>>> - >>>>>>> >>>>>>> >>>>>>> ObjectTrackingEnabled<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.objecttrackingenabled.aspx>= >>>>>>> true. DeferredLoadingEnabled = false. This situation corresponds >>>>>>> to a >>>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx>that >>>>>>> allows users to load an object graph by using >>>>>>> >>>>>>> LoadWith<http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.loadwith.aspx>directives, >>>>>>> but it does not enable deferred loading. >>>>>>> - >>>>>>> >>>>>>> Both are set to true. This is the default. >>>>>>> >>>>>>> The flags may not be changed after a query has been executed. Any >>>>>>> change after the execution of the first query that uses that >>>>>>> DataContext<http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx>throws >>>>>>> an exception. [3] >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Exceptions thrown*: >>>>>>> >>>>>>> [1] >>>>>>> System.InvalidOperationException was unhandled >>>>>>> Message="Data context options cannot be modified after results have >>>>>>> been returned from a query." >>>>>>> Source="System.Data.Linq" >>>>>>> StackTrace: >>>>>>> at >>>>>>> System.Data.Linq.DataContext.set_ObjectTrackingEnabled(Boolean value) >>>>>>> at DbLinq.Mssql.Example.Program.Main(String[] args) in >>>>>>> C:\Projects\Labs\Linq\DbLinq\examples\DbLinq.Tests\Program.cs:line 109 >>>>>>> at System.AppDomain._nExecuteAssembly(Assembly assembly, >>>>>>> String[] args) >>>>>>> at System.AppDomain.ExecuteAssembly(String assemblyFile, >>>>>>> Evidence assemblySecurity, String[] args) >>>>>>> at >>>>>>> Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() >>>>>>> at System.Threading.ThreadHelper.ThreadStart_Context(Object >>>>>>> state) >>>>>>> at System.Threading.ExecutionContext.Run(ExecutionContext >>>>>>> executionContext, ContextCallback callback, Object state) >>>>>>> at System.Threading.ThreadHelper.ThreadStart() >>>>>>> InnerException: >>>>>>> _____________ >>>>>>> [2] >>>>>>> System.InvalidOperationException was unhandled >>>>>>> Message="Object tracking is not enabled for the current data >>>>>>> context instance." >>>>>>> Source="System.Data.Linq" >>>>>>> StackTrace: >>>>>>> at System.Data.Linq.DataContext.VerifyTrackingEnabled() >>>>>>> at System.Data.Linq.DataContext.SubmitChanges(ConflictMode >>>>>>> failureMode) >>>>>>> at System.Data.Linq.DataContext.SubmitChanges() >>>>>>> at DbLinq.Mssql.Example.Program.Main(String[] args) in >>>>>>> C:\Projects\Labs\Linq\DbLinq\examples\DbLinq.Tests\Program.cs:line 109 >>>>>>> at System.AppDomain._nExecuteAssembly(Assembly assembly, >>>>>>> String[] args) >>>>>>> at System.AppDomain.ExecuteAssembly(String assemblyFile, >>>>>>> Evidence assemblySecurity, String[] args) >>>>>>> at >>>>>>> Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() >>>>>>> at System.Threading.ThreadHelper.ThreadStart_Context(Object >>>>>>> state) >>>>>>> at System.Threading.ExecutionContext.Run(ExecutionContext >>>>>>> executionContext, ContextCallback callback, Object state) >>>>>>> at System.Threading.ThreadHelper.ThreadStart() >>>>>>> InnerException: >>>>>>> _____________ >>>>>>> [3] >>>>>>> System.InvalidOperationException was unhandled >>>>>>> Message="Data context options cannot be modified after results have >>>>>>> been returned from a query." >>>>>>> Source="System.Data.Linq" >>>>>>> StackTrace: >>>>>>> at >>>>>>> System.Data.Linq.DataContext.set_DeferredLoadingEnabled(Boolean value) >>>>>>> at DbLinq.Mssql.Example.Program.Main(String[] args) in >>>>>>> C:\Projects\Labs\Linq\DbLinq\examples\DbLinq.Tests\Program.cs:line 109 >>>>>>> at System.AppDomain._nExecuteAssembly(Assembly assembly, >>>>>>> String[] args) >>>>>>> at System.AppDomain.ExecuteAssembly(String assemblyFile, >>>>>>> Evidence assemblySecurity, String[] args) >>>>>>> at >>>>>>> Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() >>>>>>> at System.Threading.ThreadHelper.ThreadStart_Context(Object >>>>>>> state) >>>>>>> at System.Threading.ExecutionContext.Run(ExecutionContext >>>>>>> executionContext, ContextCallback callback, Object state) >>>>>>> at System.Threading.ThreadHelper.ThreadStart() >>>>>>> InnerException: >>>>>>> _____________ >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 31, 2009 at 10:42 AM, Pascal Craponne <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Well, I suggest that you list all effects of such parameter >>>>>>>> (exceptions thrown when specific methods are called), and then we'll >>>>>>>> see how >>>>>>>> to implement them. >>>>>>>> >>>>>>>> Pascal. >>>>>>>> >>>>>>>> jabber/gtalk: [email protected] >>>>>>>> msn: [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 31, 2009 at 10:37, Giacomo Tesio <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hello everybody! >>>>>>>>> I've figured now that we could need a readonly DataContext for >>>>>>>>> security reasons. >>>>>>>>> In >>>>>>>>> http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.deferredloadingenabled.aspxit >>>>>>>>> is said that that would be possible, by setting >>>>>>>>> DataContext.ObjectTrackingEnabled = false. >>>>>>>>> >>>>>>>>> Actually those two proprerty required to get such a behaviour >>>>>>>>> throws NotImplementedException. >>>>>>>>> >>>>>>>>> I could try to implement them, at least to get the readonly >>>>>>>>> behaviour (which even if not trivial, should be possible in a >>>>>>>>> reasonable >>>>>>>>> time). >>>>>>>>> >>>>>>>>> Can someone get me an overview of the required modifications and >>>>>>>>> point me to the place to start? >>>>>>>>> >>>>>>>>> >>>>>>>>> Giacomo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
