Yes, the System.Data.OracleClient namespace is obsolete from .NET 4.0. RP
On Thursday, July 11, 2013 12:47:08 PM UTC+1, Alexander I. Zaytsev wrote: > > I think we shall make OracleClientDriver obsolete in 3.next and remove it > in vNext. > > What do you think guys? > > Best Regards, > Alexander > > > 2012/12/17 guilemsola <[email protected] <javascript:>> > >> Hi All, >> >> for the record the cause of the issue was the usage of the MS Oracle >> Client (System.Data.OracleClient) instead of the Oracle Data Provider >> (Oracle.DataAccess). In fluent is easy to confuse as the first one >> is OracleClientConfiguration and the ODP.Net OracleDataClientConfiguration >> as we were aware that the MS client is discontinued. >> >> Right now database performance has increased in 400% and there is no >> cursor leakage at all. So from my point of view never use the MS client. >> >> Guillem >> >> >> On Friday, November 23, 2012 12:46:53 PM UTC+1, guilemsola wrote: >>> >>> Hi Oskar, >>> >>> I haven't set **ThreadStaticSessionContext, now I did it but results >>> were the same. >>> >>> I'm using an ObjecContextFactory with a list of Factories for every >>> connection string. Then there is a ThreadStatic list of open connections >>> per thread. Every thread is responsible at the end of it's process (on a >>> catch ... finally) to close and dispose NH sessions on that list. So I >>> think I'm closing sessions in a proper way. >>> >>> BTW, due to a stress test, I have seen that Oracle is like sharing >>> cursors per session or mixing sessions or it's really me who is not really >>> closing them properly. >>> >>> AFAIK the CLR manages physical threads so that a new .Net thread can >>> recycle one already opened physical thread. Could be due to this that there >>> is a kind of mess with them? >>> >>> Regards >>> >>> On Thursday, November 22, 2012 1:09:58 PM UTC+1, Oskar Berggren wrote: >>>> >>>> 2012/11/18 guilemsola <[email protected]>: >>>> > Hi All, >>>> > >>>> > I have a multithread application with threadstatic sessions that does >>>> some >>>> > job with files. It's using NH to consume from services and running on >>>> an >>>> > oracle db, so far so good. >>>> > >>>> > Every thread has a verbose log that uses stateless session to be more >>>> > lightweight. BTW when some files are processed I can see that lots >>>> of >>>> > cursors are managed in oracle for log session. >>>> > >>>> > For instance log: >>>> > >>>> > 324 SPC_LOG >>>> > 310 SPC_LOG >>>> > 121 SPC_LOG >>>> > >>>> > and application itself: >>>> > >>>> > 31 SPC_PRODUCTION_LINE_TEST >>>> > 27 SPC_PRODUCTION_LINE_TEST >>>> > 21 SPC_PRODUCTION_LINE_TEST >>>> > >>>> > This drives me to run out of Oracle cursors ORA-01000. >>>> > >>>> > Does somebody has an idea about what could cause this? I guess that >>>> every >>>> > thread at the end of it's life closes all sessions, regular and >>>> stateless. >>>> >>>> I'm not aware of any automatic-close-session-on-**thread-exit >>>> behavior. >>>> Sessions have no concept of threads at all. Supposedly a session >>>> stored in thread static storage will go out of reach when the thread >>>> ends and eventually be garbage collected, but there are no guarantees >>>> on when that will happen. >>>> >>>> Are you using the ThreadStaticSessionContext? >>>> >>>> >>>> >>>> /Oskar >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/nhusers/-/NfeB6eYTaswJ. >> >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/groups/opt_out.
