Hi Isomorphic,
could you explain how to handle this use case best?
I have a ListGrid where one can perform a custom operation with a button shown in every row. The action itself takes ~2 seconds to process on the server and all actions on the server happen in a transaction (this is needed). This action can succeed or fail (on the server: return new DSResponse().setFailure("..."))
Now I have a BatchImport that fills the mentioned ListGrid with many records. I can't tell the user to click though all the records, so I need to offer a mass action for selected records.
I already build this and it is working fine if the action succeeds for all records. This is done in a queue.
Now my problem:
If for e.g. 2 of 10 this action does not succeed, I want the action to commit for the 8 records and to fail for the two records - so no STATUS_TRANSACTION_FAILED, but perhaps a "STATUS_SOMEREQUESTS_FAILED".
I could perhaps manually call this on the server request.getRPCManager().getDsTransaction().commit(); in order to have my successful changes persisted but getDsTransaction() is not javadoc'd and I don't think that this is how it is supposed to be. I also read the server RPCManager docs:
In this thread I asked a similar question for BatchUploader, but solved the problem there with validators that check that the ADD will work almost guaranteed, which is the correct solution there.
Now I think the correct solution for the current use case would be to have a Queue where every request on the server is handled in its own transaction.
The shortcut I can think of for now is firing many DSRequests at once without a queue (=own transaction on the server), but I'd then need a way to wait for all the responses to arrive and block the GUI until this happens.
Also this will higher the load on the server as all requests come in at once.
What is your suggestion here (I'm using 5.1p)?
Thank you & Best regards
Blama
could you explain how to handle this use case best?
I have a ListGrid where one can perform a custom operation with a button shown in every row. The action itself takes ~2 seconds to process on the server and all actions on the server happen in a transaction (this is needed). This action can succeed or fail (on the server: return new DSResponse().setFailure("..."))
Now I have a BatchImport that fills the mentioned ListGrid with many records. I can't tell the user to click though all the records, so I need to offer a mass action for selected records.
I already build this and it is working fine if the action succeeds for all records. This is done in a queue.
Now my problem:
If for e.g. 2 of 10 this action does not succeed, I want the action to commit for the 8 records and to fail for the two records - so no STATUS_TRANSACTION_FAILED, but perhaps a "STATUS_SOMEREQUESTS_FAILED".
I could perhaps manually call this on the server request.getRPCManager().getDsTransaction().commit(); in order to have my successful changes persisted but getDsTransaction() is not javadoc'd and I don't think that this is how it is supposed to be. I also read the server RPCManager docs:
Special notes on queueing
While processing a queue, the RPCManager will not abort the queue if one of the requests fail, it will instead carry on until the last request has been executed and then issue a callback to the datasources involved. The reason for this is that the code in a DMI might already handle the error condition, and that any DataSource operations performed in the context of the failed transaction might likewise be trying to compensate for the error or gather information to send back in an error message. If a request failed, theRPCManagerCompletionCallback.onFailure(com.isomorphic.datasource.DSTransaction, boolean) would be called and the datasources would either commit or rollback a transaction. If you instead wanted to abort the execution of the rest of the queue upon failure you will have to manually call RPCManager.queueHasFailures() to see if the queue has any failures before executing the next request. Also note that RPCRequests issuing DMI calls do not have the concept of commit and rollback and will therefore require you to use this method to abort a queue on failure.
While processing a queue, the RPCManager will not abort the queue if one of the requests fail, it will instead carry on until the last request has been executed and then issue a callback to the datasources involved. The reason for this is that the code in a DMI might already handle the error condition, and that any DataSource operations performed in the context of the failed transaction might likewise be trying to compensate for the error or gather information to send back in an error message. If a request failed, theRPCManagerCompletionCallback.onFailure(com.isomorphic.datasource.DSTransaction, boolean) would be called and the datasources would either commit or rollback a transaction. If you instead wanted to abort the execution of the rest of the queue upon failure you will have to manually call RPCManager.queueHasFailures() to see if the queue has any failures before executing the next request. Also note that RPCRequests issuing DMI calls do not have the concept of commit and rollback and will therefore require you to use this method to abort a queue on failure.
Now I think the correct solution for the current use case would be to have a Queue where every request on the server is handled in its own transaction.
The shortcut I can think of for now is firing many DSRequests at once without a queue (=own transaction on the server), but I'd then need a way to wait for all the responses to arrive and block the GUI until this happens.
Also this will higher the load on the server as all requests come in at once.
What is your suggestion here (I'm using 5.1p)?
Thank you & Best regards
Blama
Comment