overlapping WSARecv and OracleQuery.Execute interfere

[fullmann]

I'm using TOracleQuery in an interent server application.
To receive Messages from a socket, I'm using overlapping WSARecv with a completion-routine and waiting in an alertable WSAWaitForMultipleEvents.
When a Message comes in, I use 1 non-threaded OracleQuery to write data to DB. While the query executes, my WSARecv completion-routine fires again (?!) instead of waiting for termination of the oraclequery.execute statement.
When running again into the execute while the first execute is still in progress, my app gets the "game over"...

To prevent this effect, I changed execution mode to threaded and wait (unalertable) directly after the execute statement for an event that is set in the OnThreadFinished-Event (and then - for safety - sleeping another turn: "while ThreadIsRunning")

...

There must be a better way?! ;-)

Thanks,
Frank

 

[Marco Kalter]

If a routine fires again, while executing a non-threaded TOracleQuery, then this must be from another thread. The current thread is executing the query.

------------------
Marco Kalter
Allround Automations

 

[fullmann]

Originally posted by mkalter:
If a routine fires again, while executing a non-threaded TOracleQuery, then this must be from another thread. The current thread is executing the query.

The Delphi Thread-CallStack DebugWindow shows, that the execute Method is called twice or more by the same thread.
I register a winsockAPI callbackroutine on a socket recv-event for several sockets (all done in one thread).
When the callbackroutine fires, I execute a TOracleQuery in the same thread context.

CallStack Thread $c00:

TDB.SetGebot($117994C,1)
TConnection.cmdAngebotErhalten
TConnection.ParseCMD
TConnection.OnRead(0,29)
IOReadReady(0,29,$1188A00,0)
TDB.SetGebot($12B3CC4,1)
TConnection.cmdAngebotErhalten
TConnection.ParseCMD
TConnection.OnRead(0,29)
IOReadReady(0,29,$11915AC,0)
TOracleQuery.InternalExecute(False,True,1,0)
TOracleQuery.ExecuteArray(-1,-1)
TOracleQuery.Execute
TDB.SetGebot($12B3F1C,1)
TConnection.cmdAngebotErhalten
TConnection.ParseCMD
TConnection.OnRead(0,29)
IOReadReady(0,29,$118D000,0)
(here callback registering happens)
TListener.Execute

As you can see, the first callback IOReadReady calls the execute. While the execute does it's work, the callback comes in again. In SetGebot I wait for a signal that is set when execute has finished, so that the second and third callback don't reach the execute to prevent the app from crashing. Unfortunatly the execute never comes back now...
As described in my first posting, I tried a threaded query and some blocking but then query results get lost.

Any Ideas, PLEASE? ;-)

 

[fullmann]

...but when the problem is that i'am still in the same thread, then why don't open a new one to execute the query and everything works fine...

 

[Marco Kalter]

I'm not sure if I understand this, but doesn't this part of the call stack imply that TOracleQuery.InternalExecute has called IOReadReady?

IOReadReady(0,29,$11915AC,0)
TOracleQuery.InternalExecute(False,True,1,0)

If so, how can that be?

------------------
Marco Kalter
Allround Automations

 

[fullmann]

Originally posted by mkalter:
I'm not sure if I understand this, but doesn't this part of the call stack imply that TOracleQuery.InternalExecute has called IOReadReady?

IOReadReady(0,29,$11915AC,0)
TOracleQuery.InternalExecute(False,True,1,0)

If so, how can that be?

I suppose there are two concurrent wait operations "running", the callback registered earlier for the ioready and one in the oci-internals, both started for the same thread and both waiting for arrival of data. When the thread goes in an "alertable wait state" in the execute, the callback is able to fire too, because initiated in the same thread. The ioready receives first (the wait process in the oci is interrupted then (and hangs)).
Maybee a bad constellation of wait/callback operations...

Frank