Why are you using MTS? Transaction intensive stuff should have a dedicated
connection.
Jim
--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family. Remove the negative part, keep the minus sign. You can figure
it out.
"Dilan" <dilan_a_at_example.net> wrote in message
news:lVkxa.1764$O72.380191_at_news2.telusplanet.net...
> Looks like we have this almost solved....Whooosh..........
> I switched to using dedicated connections instead of MTS and the problem
> went away. I can actually reproduce this almost on demand. Now that I have
> narrowed this down I did a quick google group search and found that there
> were very few but similar problems reported and ongoing. When I have a
> complete answer to this problem I will post it to the news group so that
> someone who comes looking for this can find it.
>
> dilan
>
>
> "Dilan" <dilan_at_example.net> wrote in message
> news:w0Pwa.41$s14.43700_at_news0.telusplanet.net...
> > Hi,
> > I am starting to look at this from the Net8 side of things. I have found
> an
> > article on Metalink (Note:73929.1) that comes close to describing a
> solution
> > to my problem. But we are using tnsnames.ora file to establish our
> > connections. So whatever these "bequeath" protocols are I hope we are
not
> > using them. Is there a way to confirm this?
> >
> > thanks
> > dilan
> >
> >
> >
> > "Mladen Gogala" <mgogala_at_adelphia.net> wrote in message
> > news:pan.2003.05.15.13.00.02.781499_at_adelphia.net...
> > > On Thu, 15 May 2003 06:31:05 +0000, Dilan wrote:
> > >
> > > > We have been experiencing some delays in a transaction intensive
OLTP
> > > > program written in COBOL running under Win2K. After narrowing it
down
> to
> > an
> > > > embedded sql statement EXEC SQL COMMIT WORK END-EXEC., to get more
> > clarity I
> > > > re-wrote the program in C. I was able to reproduce the delay in a
> block
> > of
> > > > code that the Pro*C pre-compiler generated for the embedded SQL
> > directive
> > > > "EXEC SQL COMMIT WORK." The line reads
> > > >
> > > > "sqlcxt((void **)0, &sqlctx, &sqlstm, &sqlfpn);".
> > > >
> > > > Looks harmless, but has anyone seen anything like this before. Are
> there
> > any
> > > > name resolution operations, potential timeouts around this function
> > call.
> > > > The longest delay I have seen is about 62 seconds.
> > > >
> > > > TIA
> > > > Dilan
> > >
> > > Well, SQLLIB calls are not documented, so I cannot help you there.
> > > Have you monitored the database side? Any problems there? What does
> > > v$session_wait show during that wait? Do you have a gigantic
log_buffer
> > > that gets filled and then you have to wait for LGWR to write all of it
> > > down to something slightly slower then a 5.25 floppy? If not,
database,
> > > there is also the network component. Any problems there? Have you
tried
> > > pinging the box?
> > > If the database is 9i, set event 10046, level 10 in your session
> > > (dbms_system.set_ev will do the trick) and analyze the resulting trace
> > > file with tkprow, wait=yes. If you have good reflexes, monitor
> > > gv$session_wait as well.
> > >
> > >
> > > --
> > > Mladen Gogala
> > > Software is like sex, it is better when it is free.
> > > Linus Torvalds
> > >
> >
> >
>
>
Received on Sat May 17 2003 - 02:20:42 CDT
