tags:

views:

42

answers:

2

I'm creating my repositories with spring.net. However, I'm wondering what the lifetime is of these objects. In my repositories, objects that are retrieved from the database are cached in a registry. But this should only happen for a single server call. Can you specify in spring.net configuration that the objects should be created for each call to the server.

I guess singleton=false doesn't do it for me, as this will create a new Repository everytime, even in the same thread.

+1  A: 

This is a complicated question, because the design of the cache and registry comes into play. It sounds like the lifetime of the persistent objects will be controlled by the registry, since it will be maintaining references.

So there are a few things to ask:

  1. Which object owns the cache? The repository, the service, or something else?
  2. How are you invalidating the cache? Is it keeping track when persistent objects are updated?
  3. What's the timeout value for the session in which the objects are created? How would an invalidated session be communicated to the cache?
  4. When you say "registry", do you mean "Windows registry"? (god forbid, please so "no".)

In Spring for Java EE, one usually gets configurable caching with Hibernate and EhCache. If you use the Spring JDBC template you have to write it yourself. What implementation are you using for your repositories?

duffymo
1. Repository2. Well, that's the problem, currently it doesn't get invalidated...3. Doesn't really make a difference.4. :-) nope, that would be a sop (spaghetti oriented pattern)Well, after some reading, I know what to do next. Thx for the clear answer.
Lieven Cardoen
+1  A: 

From your previous posts I see you put all your repositories in a registry class to retrieve them.

I'd step away from that approach and inject the repositories directly into the classes that need them. Then it becomes a lot clearer what the lifetime of your objects is.

You should look at the other scopes Spring.NET has to offer as well.

BennyM
Indeed, I refactored that, although I did get it from the book from Tim McCarghy. I'll have another look at it to see what I've missed from the book. He does invalidate the cache.
Lieven Cardoen