Evaluation questions after reading the docs

Hello all

We're starting a new project and trying to figure out if LightSpeed is right for us, or if we need to go with something more complicated. I've been reading through the docs (from the nightly build 20091209) and I've got a few architectural questions I'm hoping you could help us with.

Some background on our app:

• Desktop, Single User
• In-Process Database
• Heavily multithreaded
• Reads and writes to the DB are never carried out by more then one thread at a time, but not necessarily always by the same thread
• 15 tables with up to a million rows per table (most tables have a third that number)

About 250'000 of these records we need to keep in memory from application startup to application shutdown. In between that time there exists a high probability that most of the other records will be read at some point, but we won't need them for long and should allow the GC to recover them as memory conditions require (unfortunately many of these records are large).

1.
From the documentation it seems the SimpleUnitOfWorkScope<> is what we should use. It's usage is intended to express that a database connection's lifetime coincides (more or less) with that of the application's. Correct?

2.
Is your first level cache implemented using WeakReferences to Entity<> objects? I ask because if the SimpleUnitOfWorkScope<>'s lifetime coincides with that of the entire application's, then your first level cache would never let the GC recover any objects that the application is no longer referencing.

3.
I've taken a brief look at the designer (nicely done BTW) and I'm confused by the fact that "Cascade Deletes" is an Entity-Property. Should this not be an Association-Property (or an Attribute like RemoveBehavior)? As I understand it, "Cascade Deletes" can be used to specify who is the logical owner of a certain class. Basically, if I have three associations leading to a certain class, I would usually only want cascading deletes to apply along one of them. Correct?

In our upcoming project we can assign our classes into one of two groups, lets say A or B. If the root object in either group A or B is deleted, then all the associated instances in the same group should get deleted with it. However, the cascading delete should not run along any of the associations leading to instances in the other group.

Can I get the DAL to handle this correctly, or would I need to turn cascading deletes off and handle this in the domain layer?

Thank you for your time and insight.

Kind regards -- a5cent

1. Not quite, the SimpleUnitOfWorkScope defines the lifetime of the UOW as being equal to the lifetime of the scope.  So what you describe would be true only if the SimpleUnitOfWorkScope had the lifetime of the entire application.  For whole-app lifetime, I'd tentatively suggest you'd probably need to implement a custom scope object which stored the unit of work as a static member (this would be trivial to do and we would be happy to provide guidance), but given your requirement to release references this probably isn't the right plan -- see below for an alternative.

2. No, the first level cache (identity map) holds strong references.  A possible option would be to use the second level cache, either using say the memcached provider or a custom ICache implementation which used weak references.  But this would be beneficial only if you used short-lived units of work, allowing the identity map to be reclaimed between each one.

Based on your description, the best strategy might be to use a separate unit of work to do each "transactional" block of work (where you are reading and writing records that you don't need to keep), and keep your 250000 "permanent" records in memory via the second-level cache (from where they will be pulled into the "current" UOW on demand).  You can specify different caching policies for each entity type so if the "permanent" records are of distinctive types (e.g. reference data) then this should work quite well (you'd turn caching on for the permanent types and off for the transactional types).

3. Cascade deletion can be controlled at several levels (and, I have to admit, has evolved by accretion to the point where it is rather confusing now).  Basically a delete will be cascaded if the association is non-nullable or has the Dependent attribute, *AND* CascadeDeletes is set on the LightSpeedContext or the entity that's being deleted.  The entity-level cascade delete setting is a way to override the context-level cascade delete.

So I'm not sure whether LightSpeed will be able to handle your scenario.  If you've got three associations from an entity, then you can control which ones cascade and which don't by using nullability and the DependentAttribute (e.g. when a Person is deleted, you want to delete Children but not Friends, you would make Children dependent or non-nullable, but make Friends nullable).  But if you want to cascade deletion to only specific entities *within* an association (e.g. when a Person is deleted, you want to delete male Children but not female Children), you couldn't use LightSpeed cascading, and would need to handle it in the domain layer.

Hope this makes sense -- let me know if you need more info.

Thank you for that write up.

I wouldn't expect/want the DAL to know how to cascade deletes to only specific entities *within* an association. The ability to configure cascading deletes based on types, nullability and the DependentAttribute is exactly what I was looking for. This should work well for us.

Unfortunately, our "permanent" records are not distinctive types (or only to a certain degree). I'm not 100% sure yet, but I think we would need more fine grained control over this. Basically, we would want the 2nd level cache to contain everything our application keeps references to and let the GC reclaim everything else. We don't see the cache as a means of improving performance, but as a means of insuring object identity, i.e. not materializing the same object more than once. Could we implement this behavior with our own custom cache?

If we can get a solution for that, then your other recommendation also sounds good: We should use a separate UnitOfWork for each (shortly-lived) transactional block and enable caching for... the objects our application holds references to.

What I'm still unclear about is UnitOfWork<>, UnitOfWorkScopeBase<> and if their workings are affected by the cache coming into play.

1.
Is it correct that the cache plays no role in determining if an entity is tracked or not?

2.
I've noticed that entities are not removed from a UOW after the UOW has been disposed of. Adding the same entity to a second UOW without detaching it from the first raises an exception.
a) Is it correct that after disposing a UOW we would need to call UOW.Detach(Entity) for every entity that was attached to it?
b) If so, what would be the best way to do that? I don't think we want to manage that list of attached entities ourselves if the UOW is already doing that for us, but there is no parameter less UOW.Detach().
c) I understand that this "detach from disposed UOW issue" isn't one in a scenario where session state is recreated from the database for every request/response cycle, but doesn't it also arise as soon as the cache comes into play? The cache could very well hand out entities that were previously attached to a disposed of UOW?

3.
I need a bit more information on what exactly PerThreadUnitOfWorkScope does and how it is meant to be used.

a) Does PerThreadUnitOfWorkScope.Current() hand out a UnitOfWork depending on the calling threads ID and create a new one if none yet exists for that ID?
b) The docs state: "To have units of work created and disposed on a per-thread basis use PerThreadUnitOfWorkScope". Does this mean that dispose is called for me at some point? If so, when?

Thanks again for you time and insight! -- a5cent

Yes, I think you could implement fine grained control with a custom cache.  Basically I guess you would implement ICache to inspect the item on an AddItem or SetItem, and cache it only if it was a "permanent" record, otherwise no-op it (or cache a weak reference).  LightSpeed would still call AddItem or SetItem for every entity of a cacheable type, but I don't think a custom cache provider is obligated to honour that request.

I have to admit I'm not an expert on the caching stuff but if you have more questions I can drag in someone who is!

1. Correct.  Tracking occurs at the unit of work / identity map level.  An entity is tracked only so long as it is registered in a unit of work.  Of course, if LightSpeed needs to load a particular entity and that entity is available in the L2 cache, it will pull it out of there and register it in the unit of work that needs it.  See http://www.mindscape.co.nz/blog/index.php/2009/11/05/whats-the-deal-with-lightspeed-caching/ and in particular the section "When will I get a cache hit?"

2. No, you don't have to detach an entity from its existing UOW before attaching it to another UOW.  Note you do need to use the Attach method rather than Add: Add is for adding new entities (i.e. registering a pending insert).  As there's no need to detach, the issue with the cache doesn't arise.

3a. Yes, PerThreadUnitOfWorkScope creates a UOW the first time a thread needs one, then keeps returning the same UOW for that thread; but each thread gets its own UOW.  (If you're familiar with ThreadStatic variables, it stores the UOW reference into one of those.)

3b. The docs are misleading (some would say wrong) and in my opinion the PerThreadUnitOfWorkScope itself is rather confusing.  PerThreadUnitOfWorkScope is IDisposable, so you can dispose it with a using statement, but you should never do so.  Calling Dispose on a PerThreadUnitOfWorkScope will dispose the calling thread's UOW, then prevent you from disposing any other thread's UOW -- and you will never be able to get another UOW for the thread that did the disposal!  Instead, each thread needs to dispose its Scope.Current UOW separately -- but you still can't get a new one once you've done the disposal.

For these reasons, I usually advise people to avoid PerThreadUnitOfWorkScope.  It's just misdesigned for all but the most trivial of situations.

Given your multithreading requirements (multiple threads but only one performing database activity at any given time) and that you are on board with using short-lived transactional blocks, PerThreadUnitOfWorkScope is not a good fit anyway because you want each thread when entering a transactional block to spin up a new unit of work, then dispose that on exiting the transactional block.  PTUOWS would keep using the same UOW for the lifetime of the thread, which is not what you want (because it would hold references).  Instead I think you'll want to be calling LightSpeedContext.CreateUnitOfWork explicitly (and disposing the UOW when the transactional block is done).  Obviously you can encapsulate this within a dispenser of some sort, possibly within your repository class.

Hope this makes sense -- please let us know if you have any more questions.

Sorry for the above post (can be deleted) - cut&paste from WinWord didn't work well. Here the cleaned up versio of the same post:

Understood. That cleared up a lot for me. Thank you very much Ivan.

Due to the way caching is implemented I would say LightSpeed is built primarily for use in stateless/web applications, but with a modified caching implementation could also work well in state full applications like ours. We will definitely start testing this.

Just out of curiosity, may I ask why you have an UOW.Attach() method *and* an UOW.Add() method? Based on its EntityState a UOW could certainly tell if an entity was new'ed or originated from the database and choose the correct code path accordingly, not?

I strongly suspect you guys know more than enough about what things in the documentation could use improvement to make them more clear. I think just few small additions and I wouldn't have had to claim any of your time here. But just in case you are interested I'd gladly send you a small list of suggestions.

Kind regards -- ascent

On the contrary, we are probably too close to the product to know what needs to be made clearer in the documentation, especially for people new to LightSpeed -- we would very much welcome your suggestions for improvement!

You are right that we probably could merge Add and Attach from a technical point of view -- the implementations are almost identical.  I do find when reading code that Attach makes it clear that the code is smuggling in something from an old unit of work (i.e. low-level UOW manipulation) whereas Add is simply and specifically registering a pending insert.  But it's equally arguable that this minor readability benefit doesn't justify the API clutter and discoverability issues.  I can't give you a definitive answer because that bit of the API dates back to before I joined the company...!