Perhaps you simply need to sidestep NHibernate for this particular service, which seems somewhat like a reporting scenario , or use NHibernate but with projection to avoid instantiating your entitites.
/Oskar 2011/4/20 Andrew Badera <[email protected]>: > On Wed, Apr 20, 2011 at 6:11 AM, José F. Romaniello <[email protected]> > wrote: >> >> Thing is.. That you came with lot of numbers but you cant answer what >> exactly are doing with the session. >> Nhibernate is too big and is easy to make huge mistakes, Fabio tried >> to guide you by knowing more about the problem but you instead focus >> on solutions without fully explain the problem. >> Thats okey if you dont need the help of him; > > I'd have been happy to answer Fabio's questions, once I'm back in the office > again later today and again have access to the codebase. In the meanwhile, I > simply had what I certainly consider a reasonable question, and he acted > like a jerk to prove how superior he obviously is. Perhaps his mommy didn't > love him enough, but I simply don't need his sort of grief. Life is better > without people like that in it. > >> >> -use session per view or a short lived session >> -use stateless session >> -use readonly session (new in 3.2) > > Looking into these now. > >> >> -use idbag > > Hadn't heard of this ... looked at the doc. Will look further here. > >> >> -4000 entities in a data service? Dont know what you mean with that if >> it is a webservice you are doing it wrong. You vaguely need that >> amount of entities at once and with full collection initialized. > > It's essentially a pure data service and the call is for our entire catalog > to populate remote devices and other clients; I'm not the one who designed > it, and I understand there were a lot of politics involved in some of the > design decisions, both in DB schema and service contract design. There are > already clients dependent upon this service, and they're all on the cusp of > release to production. As such, I, as the new guy, am really not in a > position to push for changes that would dictate a lot of changes to clients, > so method signatures and resultsets unfortunately can't really be changed > overly much at the moment. Me? I'd have done a much lighter weight call > initially, and pulled specific details as-needed in one or more subsequent > calls. > >> >> -use second level cache > > Under consideration; putting AppFabric up now, and I have the bits for the > nHibernate AppFabric (Velocity) integration. Awaiting the AppFabric nodes > being provisioned by people responsible for server resources at the moment. > However, while, yes, this would allow a warmup/priming behavior, the first > call is still going to take longer than I'd like. > >> >> -enhance your mappings >> -enhance you model > > There isn't much love for the EAV schema around here, but again, due to > politics, the ability to change that may be limited. Pushing for it, as I > believe EAV is the root of the problem here, but no guarantees of > improvements here. > >> >> This is all i can think of without futher information. The order of >> the things i said doesnt matter. > > Thanks for your input, appreciated! > --ab > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" 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/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en.
