In Corda, I am running flow tests using a MockNetwork. I am trying to retrieve a transaction from one of the nodes' transaction storage using:
node.services.validatedTransactions.getTransaction(signedTx.id)
However, this is throwing the following exception:
com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IllegalStateException: Was expecting to find transaction set
on current strand: Thread[main,5,main]
What is the cause of this error?
Whenever you need to access a MockNode's database, you need to do so inside a database transaction:
node.transaction {
node.services.validatedTransactions.getTransaction(signedTx.id)
}
Related
I see a bunch of 'permanent' failures when I fire the following command:-
.show ingestion failures | where FailureKind == "Permanent"
For all the entries that are returned the error code is UpdatePolicy_UnknownError.
The Details column for all the entries shows something like this:-
Failed to invoke update policy. Target Table = 'mytable', Query = '<some query here>': The remote server returned an error: (409) Conflict.: : :
What does this error mean? How do I find out the root cause behind these failures? The information I find through this command is not sufficient. I also copied OperationId for a sample entry and looked it up against the operations info:-
.show operations | where OperationId == '<sample operation id>'
But all I found in the Status is the message Failed performing non-transactional update policy. I know it failed, but can we find out the underlying reason?
"(409) Conflict" error usually comes from writing to the Azure storage.
In general, this error should be treated as a transient one.
If it happens in the writing of the main part of the ingestion, it should be retried (****).
In your case, it happens in writing the data of the non-transactional update policy - this write is not retried - the data enters the main table, but not the dependent table.
In the case of a transactional update policy, the whole ingestion will be failed and then retried.
(****) There was a bug in treating such an error, it was treated as permanent for a short period for the main ingestion data. The bug should be fixed now.
I'm trying to debug a deadlock on Redshift:
SQL Execution failed ... deadlock detected
DETAIL: Process 7679 waits for AccessExclusiveLock on relation 307602 of database 108260; blocked by process 7706.
Process 7706 waits for AccessShareLock on relation 307569 of database 108260; blocked by process 7679.
Is there a sql query to get a description for process ids 7679 and 7706?
select * from stl_query where pid=XXX
This will give you the query txt which will help you identify your query.
You can also query stv_locks to check is there are any current updates in the database, and str_tr_conflict will display all the lock conflict on the table.
I want to use Datastore from Cloud Compute through Java and I am following Getting started with Google Cloud Datastore.
My use case is quite standard - read one entity (lookup), modify it and save the new version. I want to do it in a transaction so that if two processes do this, the second one won't overwrite the changes made by the first one.
I managed to issue a transaction and it works. However I don't know what would happen if the transaction fails:
How to identify a failed transaction? Probably a DatastoreException with some specific code or name will be thrown?
Should I issue a rollback explicitly? Can I assume that if a transaction fails, nothing from it will be written?
Should I retry?
Is there any documentation on that?
How to identify a failed transaction? Probably a DatastoreException
with some specific code or name will be thrown?
Your code should always ensure that a transaction is either successfully committed or rolled back. Here's an example:
// Begin the transaction.
BeginTransactionRequest begin = BeginTransactionRequest.newBuilder()
.build();
ByteString txn = datastore.beginTransaction(begin)
.getTransaction();
try {
// Zero or more transactional lookup()s or runQuerys().
// ...
// Followed by a commit().
CommitRequest commit = CommitRequest.newBuilder()
.setTransaction(txn)
.addMutation(...)
.build();
datastore.commit(commit);
} catch (Exception e) {
// If a transactional operation fails for any reason,
// attempt to roll back.
RollbackRequest rollback = RollbackRequest.newBuilder()
.setTransaction(txn);
.build();
try {
datastore.rollback(rollback);
} catch (DatastoreException de) {
// Rollback may fail due to a transient error or if
// the transaction was already committed.
}
// Propagate original exception.
throw e;
}
An exception might be thrown by commit() or by another lookup() or runQuery() call inside the try block. In each case, it's important to clean up the transaction.
Should I issue a rollback explicitly? Can I assume that if a
transaction fails, nothing from it will be written?
Unless you're sure that the commit() succeeded, you should explicitly issue a rollback() request. However, a failed commit() does not necessarily mean that no data was written. See the note on this page.
Should I retry?
You can retry using exponential backoff. However, frequent transaction failures may indicate that you are attempting to write too frequently to an entity group.
Is there any documentation on that?
https://cloud.google.com/datastore/docs/concepts/transactions
While saving data in Pega PRPC using activity with Obj-save method, I got following error message:
pyCommitError: A commit cannot be performed because a deferred save of instance ANDY-FW-ANDYCARRENTALFW-DATA-CARINFO L3 failed: code: SQLState: Message:
Can anyone share some idea on how to fix this issue?
Andy
This message could come when we have a field which has a less field length specified in DB and we are trying to insert bigger string in the field.
There could be other reasons as well.See Tracer.
Deferred save of instance usually fails due to locked instance which you are trying to commit. Or the record you are trying to commit is stale (someone else committed before your commit)
Ideally, this behavior can be observed because of the lock on the work object not being held while you are trying to save the object. Make sure you acquire the lock before updating and save.
Additionally please check if privilege is given to the operator.
I have some piece of code in my Website which adds the details into tables. Now I want that if some error occurs the previously entered data should be removed. How can I implement it with the help of transactions??
We need more details such as what database you are using and so forth. Basically you do this:
Create a transaction
Do some work in the context of that transaction
Do some more work in the context of that transaction
...
If an exception occurred, rollback the transaction, else commit.