Re: Finally which ORM tool?

James Crosswell <james@xxxxxxxxxxxxxx> wrote:
Jon Skeet [C# MVP] wrote:
The decision to be session-based or not is pretty fundamental to an
ORM. If you don't want to use sessions, use an ORM which isn't session-
based, such as LLBLGen - but please don't try to suggest that no ORMs
should use sessions and manage aliasing and identity issues just
because they happen not to be issues for you.

I think you're intentionally mashing my words up here. I never said any
such thing. I said that ORMs should not REQUIRE us to use sessions in
order to persist and load objects.

What I did NOT say (and which you suggested I did) is that ORMs
shouldn't provide session capabilities. I think they're just fine and
dandy and a nice feature. However I see no reason why they shouldn't be
OPTIONAL and I've provided some pretty good examples why they should be...

Let me rephrase then:

It is easier to write an ORM system which has a rich session system if
you force sessions to be used everywhere: it means that every layer of
the ORM framework code can rely on sessions being available.

If you don't want to use sessions, I would suggest you use an ORM which
makes them optional, understanding that there may well be session-based
features which aren't available because the sessions aren't pervasive
in that system.

That's the great thing about having a choice of frameworks. I have to
say that the fact that most ORM frameworks I've come across *do* have
identity management suggests that the requirement for it isn't as rare
as you seem to be making it out to be. If sessions have no benefit for
most people, why do you think the framework developers include them?

Why do we have TCP and TCP/IP ports if developers don't use TCP/IP? The
fact is, LOTS of applications use TCP/IP - but that's no reason to force
ALL applications to use it. I'm making pretty much the same case here
but you don't seem to be following my reasoning very well.

I don't see the analogy at all, I'm afraid.

You need to distinguish between the idea of a per-request session and a
"per user transaction" session. Again, Hibernate in Action deals with
this very well.

Unless by per user transaction you mean a one thread per client model
for the server threads then I don't see how this makes a difference.

I mean a session which is potentially split over multiple client/server
requests.

<snip>

Otherwise though, you're not guaranteed to get the same thread from the
thread pool on the server in the request that you make to Save a
persistent object as you did in the request that you made to Fetch that
persistent object from the app server in the first place - and thus
you're not guaranteed to get the same session (with your ORM).

Absolutely, and Hibernate certainly isn't based on the idea of
retrieving the original thread for a subsequent request.

So although a distinction between per-request and per-user sessions is
perhaps relevant for a one thread per client thread strategy, I try to
stay away from such a beast (for the reasons above). Stateful servers
are just plain unreliable, by design.

The distinction is relevant in a more general way, but I don't have the
time or expertise to go into details here. I really do thoroughly
recommend the Hibernate book though - even if you never touch
Hibernate, it discusses a lot of very useful issues which are likely to
affect developers doing *any* database-related development.

The Hibernate authors have put in a *lot* of thought when it comes to
this kind of thing, and they're certainly *not* just thinking of
desktop client/server apps.

Well the DevExpress guys put a lot of thought into XPO - it's a really
well designed product... very easy to use etc. and it's evident that
they put a huge amount of effort into developing an extremely polished
framework there. However, at the same time it's clear that very little
of that care and attention was given to how XPO could be used in an
n-tier solution until very recently (at the insistence of many
customers, myself among them, and they haven't as yet released anything
in this regard so I'm still waiting to see what the results will be)...

I'm not shy of pointing out possible improvements, even for very mature
frameworks. Whilst often this is simply a result of my lack of knowledge
of the frameworks features (in which case usually someone sets me right
quick enough, which is ideally what I'm after) I don't think this is the
case here.

You're quite right, nHibernate is not the only ORM to incorporate the
idea of sessions and, indeed, it's not the only one to make it
obligatory (XPO being case in point). This is exactly my frustration
though - I think they all do so unnecessarily and, as yet, I've yet to
hear a convincing argument to the contrary.

This is why I'm recommending the Hibernate book: it explains the
session handling, including the pitfalls and the reasons behind it,
very well.

When one framework forces you into a particular and irritating mindset,
it can be seen as a mistake. When several (including the most commonly
used ones) do so, it's worth taking a step back and looking for the
underlying reasons. The experts are best placed to do that, and I don't
claim to be an expert in ORM in general.

(As another couple of data points, LINQ to SQL has the same session
bias, and I believe that the ADO.NET Entity Framework does too.)

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Finally which ORM tool?
    ... If you don't want to use sessions, use an ORM which isn't session- ... such as LLBLGen - but please don't try to suggest that no ORMs should use sessions and manage aliasing and identity issues just because they happen not to be issues for you. ... With such a threading strategy the server creates a thread for a client application when it first connects/authenticates and leaves this thread running for the duration of a user's "connection" to the application server... ... I'm not shy of pointing out possible improvements, even for very mature frameworks. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Finally which ORM tool?
    ... to represent the same state as the server, so the aliasing wouldn't ... between your n-tier application server and client in an pure ADO.NET ... If you don't want to use sessions, use an ORM which isn't session- ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: web application ends with no reason
    ... sessions for this exact reason. ... >> and do a search for <processModel, you'll see a number of reasons why ... >> ASP.Net's worker process will recycle...maybe it ran out of resources ... >>> no entry in the event log or IIS log. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Differenz between developing websites with PHP/LISP
    ... Ah, you meant web sessions. ... But i will look at the manual of the framework to discover how the ... different packages support different implementations. ...
    (comp.lang.lisp)
  • Re: running multiple encoder sessions
    ... Usually 4 is a sensible upper limit for a variety of reasons. ... There's no "option" for sessions, just start a second instance of the ... Encoder from the Programs menu. ...
    (microsoft.public.windowsmedia.server)