I need to delete a transaction from my GA report. All the methods I found can only refound the costs, but not delete the transaction. So I was thinking, "What happens if I delete the Client ID?".
Has anyone tried this?
Related
If I have have multiple clients writing to the same document in a transaction, is every transaction triggering the snapshot listener? If yes is it guarenteed that the listener are triggered in the order the transactions are commited? I would expect yes, but am a bit unsure because:
If a document write is performed the local Snapshot gets notified immediately cause of latency concerns. Does this "local" notification only get triggered if the transaction is guranteed to be successfull? Otherwise order would not be guaranteed right?
There is a onSnapshotsInSync method. Out of the documentation I don't really get if this is related to my question, but the method irritates me a bit. When should this method be considered, is my question somehow related to it?
Thanks
I would assume that a listener is only triggered, when the transaction is actually completed. And after the transaction is finished, I'd expect all changes to be committed to the database at once.
onSnapshotInSync only ensures that multiple listeners are in sync with each other.
After reading the documentation, there is one thing that is not completely clear to me, I am hoping someone can clarify.
Obviously if you have two read-then-write transactions that occur concurrently, one of them will fail. However, if you have one read-then-write transaction in progress, and then another read occurs that was not part of a transaction, will that other non transactional read cancel the transaction, i.e. A transaction to read-then-write on a payment/transaction record should not be cancelled by the non transactional "Get all payment data" report. Is that correct?
Yes, that's correct. Non-transactional reads and read-only transactions do not contend with read-then-write transactions.
With a Read Committed ODBC connection I'm getting the odd record lock when reading from OpenEdge's Auditing tables (Database user table CRUD operations)...
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Failure getting record lock on a record from table PUB._aud-audit-data.
I understand isolation levels and know that this can be resolved by changing to read uncommitted.
Obviously the main danger in doing this is that dirty reads become a possibility. Dirty reads would definitely cause my solution issues so would be a no-go. But...
Does the very nature of OpenEdge Auditing prevent possible dirty reads of the source records being CRUDed?
here's my thinking behind the question...
With my configuration, OpenEdge audit records are created upon completion of CRUD operations against the user tables. I want to make sure that I only read audit records where the user table CRUD operation has committed to the database. I suspect that this is always the case and that the audit records are only created after committal of the user table CRUD transaction. If this is the case then it would only be under exceptional circumstance that the audit records transactions would be rolled back and therefore dirty reads of the audit records are not really a possibility...
Is that feasible?
Can anyone clarify the life-cycle of a user transaction followed by an audit transaction in OpenEdge?
I assume it is unlikely but possible for the audit transaction to fail, in this case what happens to the original, audited, CRUD operation?
Is there any way in SQLite to determine when a new transaction has started, or which transaction is currently in progress?
The purpose for this is in a trigger which is logging certain changes to a database. As far as I can tell, a trigger has no indication as to whether the given operation is by itself or part of a set of other operations. Something like a transaction count would allow for a clear delineation of which changes occurred atomically at the same time (e.g. for the purpose of playback).
SQLite has commit and rollback notification callbacks, which are called at the end of any transaction.
The Google App Engine documentation at https://developers.google.com/appengine/docs/java/datastore/transactions says this:
Note: In extremely rare cases, the transaction is fully committed even
if a transaction returns a timeout or internal error exception. For
this reason, it's best to make transactions idempotent whenever
possible.
What is the proper way to recover from a commit exception if the transaction is not idempotent?
I think what you do is show the end user an error with a link they can use to view the state of their world. Then the end user can decide whether to resubmit. E.g. if they post a comment to a blog and the post somehow reports an error, they can re-load the blog page and see if their comment is there; if they see it's not, they can (hopefully) recover it from their browser history and resubmit.