>> What about the difference between Thread bound datacontext and
>> session bound
>> data context? Which would be more appropriate for a stateless web
>> service
In a webapp scenario session DataContext is repeatedly bound to a
request thread, so both patterns are at work at the same time.
On Jan 10, 2006, at 10:35 PM, Cris Daniluk wrote:
> Now, if its truely stateless - where each request can be assumed to
> have little in common with the previous, then I would personally think
> creating a new DataContext for each request is the way to go. Since
> the DataContexts aren't really threadsafe anyway, it probably doesn't
> make sense to do it any other way.
To add to that... If there are no real sessions (i.e. no state stored
between requests), you can create a pool of DataContexts and randomly
bind context instances to threads (making sure you rollback any
changes at the end of request cycle). Under some circumstances you
may get extra performance benefits from ObjectStore caching ... But I
would think that generally any such benefit would be negligible. So I
second Cris's advice - you are better off creating a fresh DC on
every request. Only consider the pool solution if you have profiling
data that proves otherwise.
Andrus
This archive was generated by hypermail 2.0.0 : Tue Jan 10 2006 - 22:47:19 EST