There is a code in DataUserManual about Asynchronous Execution:
Statement stmt = (ses << "SELECT (age) FROM Person", into(age), async); // asynchronous statement
Statement::Result result = stmt.execute(); // executes asynchronously
stmt.execute(); // throws InvalidAccessException
It's about that we should always call wait on result before execute a next request.
What about a case when I don't expect any answer on requests from DB? Is is safe to asynchronously call a chain of UPDATEs without waiting for result?
The reason for the exception is because the statement is still executing. If you want to issue updates in parallel, you need separate Statement objects.
Related
First of all, I have a server stream method. In the method, I will request an actor in a loop. I expect that after each request is responded, the application will return the result to the caller. But no, I found that it still waits for all responses to be completed before returning, is this normal?
// The code is as follows, for the convenience of observing the results, I added sleep
override def itKeepsReplying(in: HelloRequest): Source[HelloReply, NotUsed] = {
Source(1 to 10).map(index => {
Thread.sleep(5000)
HelloReply(character.toString)
})
}
In order to confirm whether grpc itself supports, I tried java's implementation of this piece，
If you want to send data to the caller： responseObserver.onNext(responseBuilder.build());,
If you want to end this call： responseObserver.onCompleted(); ,
Data is sent to the caller every time onNext is called.
So my question is:
Is my assumption correct? If akka-grpc can do it
If it can be done, please give an example
In a project I have to use an imported C function that sends a request to a server and receives a response. It is possible to provide a timeout parameter to this function to specify the maximum time before the blocking function returns if the server is not reachable.
Unfortunately this timeout is not always reliable and often the maxium timeout value is exceeded. What is the best Ada approach to handle this kind of problem?
After reading this chapter I am not sure if I could use this kind of programming pattern? The imported C function is not thread safe so only one request at a time is possible. A perfect solution would allow one to send a request (with a valid response or the timeout response normally returned by the imported C function) and a second function could be used to query if the last request timed out. Until the imported C function call has returned further requests should always return the timout response.
I am not sure what happens to the entries (programming statements inside the entries) Password_Server.Set and Process_Data.Output call if the delay alternative is chosen?
If the entry call is queued or waiting for access to a protected object (PO), then the entry call is aborted when the delay expires, the delay branch is executed, and the select finishes. If the entry call has been accepted (task) or is executing (PO) when the delay expires, it continues until it finishes or is requeued. If it finishes, then the entry branch is executed and the select finishes. If it is requeued with abort it behaves just as it does initially. If it is requeued without abort, then the delay branch is ignored. (Note that if it's requeued without abort, it can still be later requeued with abort, so things can be more complicated. It's best to try to avoid such a design.)
IIUC correctly, you want only one task at a time to be able to call the C operation. If one task is calling it and another tries to, the second task should be told the call timed out. Ada should abort the C operation if it takes longer than its timeout.
The only way I can see to abort the call to C is with an Asynchronous Transfer of Control. Whether that will actually do what is wanted is an open question.
This leads me to something like
package Calling_C is
type Data is ...
procedure Call_C (Info : in Data; Timeout : in Duration; Timed_Out : out Boolean);
end Calling_C;
package body Calling_C is
task Control is
entry Call_C (Info : in Data; Timeout : in Duration; Timed_Out : out Boolean);
end Control;
task body Control is
begin
Forever : loop
select
accept Call_C (Info : in Data; Timeout : in Duration; Timed_Out : out Boolean) do
select
delay Timeout;
Timed_Out := True;
then abort
-- Call the C operation
end select;
end Call_C;
or
terminate;
end select;
end loop Forever;
end Control;
procedure Call_C (Info : in Data; Timeout : in Duration; Timed_Out : out Boolean) is
begin
select
Control.Call_C (Info => Info, Timeout => Timeout, Timed_Out => Timed_Out);
else
Timed_Out := True;
end Select;
end Call_C;
end Calling_C;
The first task gets in and calls the C operation. Subsequent tasks are not accepted immediately and return with Timed_Out set to True. If the call to C doesn't return in time, maybe it's aborted.
I don't actually know Ada very good just yet. Posting my idea here so pros can tell me whether it's a bad idea. The server would look something like this:
task Server is
entry Request (in Input : Input_Type);
entry Response (out Output : Output_Type);
end Server;
task body Server is
Local_Input : Input_Type;
Local_Output : Output_Type;
begin
accept Request (Input : in Input_Type) do
Local_Input := Input;
end Request;
Local_Output := My_C_Code(Local_Input);
accept Response(Output : out Output_Type) do
Output := Local_Output;
end Response;
end Server;
How to use it:
Server.Request(Input);
select
Server.Response(Output);
-- got your response
or
delay Timeout;
-- response timeout
end select;
As you may have realized the Server will block on Response until the Request caller (or anyone else) decides to call it. My best guess is either a) adding select ... or terminate, or b) handle the timeout and go back to waiting for Response, sync or async.
I'm sending messages using an asynchronous write operation, but when the app is closed I need to write 2 messages to a device, but only 1 message gets successfully written.
Each write operation is chained to a message queue, so the messages write operations are sent sequentially after each completed write operation while the message queue is full. So basically the following code might get to the first completed callback, but it doesn't reach the 2nd before the app closes. I tried adding a Windows Sleep call in between and after Async Operations, but this didn't work. I also tested waiting for the completion callback using a while loop to see if the 2nd opertation ever completes, which it never does.
ComPtr<IAsyncOperation<GattCommunicationStatus>> writeOp;
GattWriteOption option = GattWriteOption_WriteWithoutResponse;
hr = customCharacteristic->WriteValueWithOptionAsync(buffer.Get(), option, &writeOp);
hr = writeOp->put_Completed(Callback<IAsyncOperationCompletedHandler<GattCommunicationStatus>>
(this, &DataGloveBluetooth::OnCharacteristicWriteComplete).Get());
This is only an issue on app close as it seems 2nd operation never gets to the callback. Also, the messages are too large to put together, so I need to be able to send more than 1 message.
Is there a proper way I can wait? This is some pseudo-code to help explain the ordering:
WriteMessage(LED_RESET); // adds to message queue, then calls aync op,
WriteMessage(CLOSE); // adds to message queue, async op is called once first message is sent, complete callback is never reached
Sleep(5000) // whatever sleep amount never helps the 2nd message finish
I had to write a Web API to insert data into custom on-premise DB and then call a stored procedure for LogicApps to use. The LogicApps' call timeouts when passing large amopnts of data. So I'm trying to use this solution I found here:
LogicAppsAsyncResponseSample
So I would basically put all my code into the doWork like this:
foreach (var record in records)
{
...
//Insert record
cmd.ExecuteNonQuery();
}
...
//Call SP
cmd.ExecuteNonQuery();
runningTasks[id] = true;
My question is should I make my code in doWork, asynchronous? Use Await as needed and ExecuteNonQueryAsync instead of ExecuteNonQuery and add AsynchronousProcessing to my connection string?
Alternatively, too I was actually considering writing this to be "Fire and Forget". Meaning I would start a thread in my API to call doWork as in the sample and return OK instead of Accepted right away. Then I wouldn't need to store thread statuses or have the chekcStatus method. This is OK for me since the API can send alerts if anything fails. The only advantage to the noted sample is I can eventually return something to LogicApps indicating success or not and show it in my LogicApps' log (one place to see all). Is "Fire and Forget" a sound practice?
FYI: the call to dowork in the sample is:
new Thread(() => doWork(id)).Start();
I'm doing some more working with AJAX, and JSON calls, and I've noticed the the SqlCommand Object has a two methods, ExecuteNonQuery(), and ExecuteNonQueryAsync(), what exactly are the differences in these methods?
If you call ExecuteNonQuery your code will wait until it completes.
If you call ExecuteNonQueryAsync your code will continue execution and you can track when the actual call to ExecuteNonQueryAsync completes via Task<int> object that it returns.