On Thu, 2010-01-14 at 10:40 -0800, Matt wrote:
> Hi! I'm having a problem with DbLinq and PostgreSQL. Take a look at
> the following scenario.
> 
> 1. I retrieve an entity from the database from Client 1
> 2. I retrieve an entity from the database from Client 2 and make some
> changes to it
> 3. I submit the changes from Client 2
> 4. I retrieve the entity again from Client 1
> 
> The problem is at step 4, the returned entity is the same cached
> entity. How can I force DbLinq to refresh it?

The question is, how are you getting into this scenario.

By design, DbLinq will cache certain entities and not query the DB for
them; see e.g. [0] and the comment on G16_CustomerCacheHit().  (Now,
admittedly DbLinq doesn't actually pass this test, meaning we're not
caching properly, but at some point DbLinq will cache as .NET
Linq-to-SQL does, and Linq-to-SQL *does* pass that test properly).

I think the problem is that your DataContext is long-lived, and they're
not supposed to be long-lived (for a variety of reasons previously
discussed on this list over the last summer, iirc).

DataContexts should be *short* lived, generally scoped to a method, and
create anew each time you need to query it.  If you do this, you're
unlikely to hit a scenario where Client 1 gets an entity, Client 2
changes it, and Client 1 again queries the entity, because the time
frame works against you (unless Client 1 is Thread.Sleep()ing for an
extended period of time, which has its own set of scalability problems).

 - Jon

[0]
http://dblinq2007.googlecode.com/svn/trunk/src/DbLinq/Test/Providers/WriteTest.cs


-- 
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.


Reply via email to