Currently I have setup ripple mainnet server and provide availability of XRP trading, If any user submits the transaction in his account from the external wallet, How I know which transaction performed?
Currently, I have used WebSocket socket and subscribe all account to the listener, So when any transaction comes in subscribed account then it will catch the transaction. But the issue is that when my xrp server is down or listeners missed any transaction then how we fetch incoming transaction later.
When you get your next transaction.
You check that account's PreviousTxnLgrSeq and see if that matches with the latest tx on your end. You can find that from the account_info API method.
Or you can query account_tx to see if the latest tx you got on your end matches with just previous tx. And if those don't match,... you've got the answer above in the account_tx method.
One downside to this practice is that you have to wait until someone deposits again to that particular account.
To avoid such circumstances, you can track every accounts' latest tx ledger sequence on your end. So if you've missed some ledgers you would know which accounts are lagging behind and check if those accounts have transactions that you've missed using account_tx method with the ledger_index_min set to the latest tx ledger sequence and ledger_index_max set to -1.
In other words this means check this account's transactions since i've last checked until the latest ledger... anyway I hope you get the idea. Godspeed! ;)
Related
I am using web3 to perform ethereum transactions. I have been able to perform the transaction, but I want to notify the user if the transaction is successful and has been mined. How would i do this in node.js?
I have tried to find ways to use a webhook on the reciever ethereum wallet in order to notify the server if a transaction on the blockchain has been mined. After that i would be able to notify the user.
My last option is to create a multi threaded loop on my server that checks if the transaction hash has been mined.
I am unsure if I should provide any code, as I don’t know if it will help.
You can use the web3.eth.getTransactionReceipt method to get a receipt for a transaction, or wait for an event generated by a smart contract when your transaction is being executed.
However, you should take into mind that public Ethereum may have forks and you should wait 5-6 blocks to make sure that the transaction will not be dropped along with the "side" fork.
I am using Stripe with the separate charges and transfers flow. The way this goes is that my platform receives the full payment minus the Stripe fees, and then I do a Transfer to the seller's connected account, which is then paid out to their bank. I set up a webhook to run on the "transfer.paid" event, so I can update some book-keeping records on my platform's database when the money is transferred to the connected account. I wish to test this endpoint so that I can see whether my event behaves as expected. However, it seems that the webhook testing available through the Stripe Dashboard sends only dummy data, or only populates a few items of the request body with data from the last transaction made in the account. It seems the only way to receive real data is to allow the event to trigger by itself. In my case, though,the transfers are taking up to seven days to complete, which means I have to send and wait a whole week to see the result, which is really slowing down my development time. This seems really inefficient, unless there is something fundamental that I am not understanding about webhooks. Does anyone have any idea how I can test my webhook endpoints with real data without having to wait so long? Any info will be greatly appreciated.
Unfortunately the only way to test events with 'real' payloads for some things like Subscription-based events and Payouts is to wait for the event to occur in testmode.
I want to send the event to Microsoft Event-hub with Db transaction:
Explanation:
User hit a endpoint of order creation.
OrderService accept the order and put that order into the db.
Now Order service want to send that orderId as event to another services using the Event-hub.
How can I achieve transactional behaviour for step 2 and 3?
I know these solutions:
Outbox pattern: Where I put message in another table with order creation transaction. And there is one cron/scheduler, that takes the message from table and mark them delivered. and next time cron will take only not delivered messages.
Use Database audit log and library that taken of this things. Library will bind the database table to Event-hub. Then on every update library will send that change to Event-hub.
I wanted to know is there any in-built transactional feature in Event-hub?
Or
Is there any better way to handle this thing?
There is no concept of transactions within Event Hubs at present. I'm not sure, given the limited context that was shared, that Event Hubs is the best fit for your scenario. Azure Service Bus has transaction support and may be a more natural fit for your intended flow.
In this kind of distributed scenario, regardless of which message broker you decide on, I would advise embracing eventual consistency and considering a pattern similar to:
Your order creation endpoint receives a request
The order creation endpoint assigns a unique identifier for the request and emits the event to Event Hubs; if the send was successful it returns a 202 (Accepted) to the caller and a Retry-After header to indicate to the caller that they should wait for that period of time before checking the status of that order's creation.
Some process is responsible for reading events from the Event Hub and creating that order within the database. Depending on your ecosystem's tolerance, this may be a dedicated process or could be something like an Azure Function with an Event Hubs trigger.
Other event consumers interested in orders will also see the creation request and will call into your order service or database for the details using the unique identifier that as assigned by the order creation endpoint; this may or may not be the official order number within the system.
To my knowledge, there isn't a way to do timed transaction in Hyperledger Fabric.
Consider the use case using the marbles example. Say I want to transfer a marble 600 seconds after I received it. Does the Fabric SDK provide anyway for me to get the unix timestamp of the event when I received my marble then send another transaction to a queue that will happen exactly 600 seconds later by calculating the timestamp + 600?
As you are talking about the time when the Marbles are actually received, then in my opinion you have to write some code on both sides. i.e, both at client and the chaincode sides.
I am not sure how to do the same with only SDK/Client side code.
If you are willing to write something in your transaction processing logic, there is a method ChaincodeStubInterface.GetTxTimestamp() in the github.com/hyperledger/fabric/core/chaincode/shim package to get the time when the transaction is processed by the Fabric.
You could return the same to your SDK, and then to your external calling program. And then compute the +600 seconds and send the next transaction.
No, there is no way to automate a timed transaction from within the chaincode and it would be bad practice to try handle it there. If you try to create a timestamp from within the chaincode, it is guaranteed that all peers processing the transaction proposal will return different values as they do not all being processing the proposal at the same exact instance. Since the results sets will return non-deterministic, the transaction will always fail when it enters the validation phase. If you try to use stub.GetTxTimestamp() you will only be returning the timestamp that the client itself sent up, as per the docs.
The best way to do this is with pure sdk code. After acquiring requisite transaction proposals and sending the transaction for ordering, listen for a transaction commitment event.
Upon receiving notification of transaction commitment, you can queue up another transaction to be sent endorsement and commitment 600 seconds later. The specifics of how will differ from sdk to sdk, but all sdk's support notification of transaction commitment.
I'm new to Azure Service Bus and I'm trying to establish a transactional strategy for queuing messages. Since SQL Azure doesn't support MSDTC and, therefore, with a distributed TransactionScope, I can't make use of it. So, I have a Unit of Work that can handle my database transactions manually.
The problem is that I can only find people using TransactionScope to handle both database and Azure Service Bus operations. Is there any other magical way to achieve transactions on Service Bus without using TransactionScope?
Thanks.
If you will be using cloud hosting or service like azure service bus, you should start considering to give up on two phase commits (2PC) or distributed transactions (DTC).
Instead, use a per-resource transactions (i.e. a transaction for a SQL command or a transaction for a Service Bus operation) carefully. And avoid transactions that cross that resource boundary.
You can then knit those resources/components operations together using reliable messaging and patterns like sagas, etc. for workflow management and error compensation. And scale out from there.
2PC in the cloud is hard for all sorts of reasons (but not impossible, you still can use IaaS).
2PC, as implemented by DTC, effectively depends on the coordinator and its log and connectivity to the coordinator to be very highly available. It also depends on all parties cooperating on a positive outcome in an expedient fashion. To that end, you need to run DTC in a failover cluster, because it’s the Achilles heel of the whole system and any transaction depends on DTC clearing it.
I'll quote a great example here of how to think of a 2PC transaction as a series of messages/actions and compensations
The grand canonical example for 2PC transactions is a bank account transfer. You debit one account and credit another.
These two operations need to succeed or fail together because otherwise you are either creating or destroying money (which is illegal, by the way). So that’s the example that’s very commonly used to illustrate 2PC transactions.
The catch is – that’s not how it really works, at all. Getting money from one bank account to another bank account is a fairly complicated affair that touches a ton of other accounts. More importantly, it’s not a synchronous fail-together/success-together scenario.
Instead, principles of accounting apply (surprise!). When a transfer is initiated, let’s say in online banking, the transfer is recorded in form of a message for submission into the accounting system and the debit is recorded in the account as a ‘pending’ transaction that affects the displayed balance.
From the user’s perspective, the transaction is ’done’, but factually nothing has happened, yet. Eventually, the accounting system will get the message and start performing the transfer, which often causes a cascade of operations, many of them yielding further messages, including booking into clearing accounts and notifying the other bank of the transfer.
The principle here is that all progress is forward. If an operation doesn’t work for some technical reason it can be retried once the technical reason is resolved.
If operation fails for a business reason, the operation can be aborted – but not by annihilating previous work, but by doing the inverse of previous work. If an account was credited, that credit is annulled with a debit of the same amount.
For some types of failed transactions, the ‘inverse’ operation may not be fully symmetric but may result in extra actions like imposing penalty fees.
In fact, in accounting, annihilating any work is illegal – ‘delete’ and ‘update’ are a great way to end up in prison.
You can use TransactionScope. It works pretty well. Even though you have sent a message, but something other (database update) fails, then the message will be not published to the queue.
using var scope = new TransactionScope(TransactionScopeOption.RequiresNew, TransactionScopeAsyncFlowOption.Enabled);
try
{
var messageBody = "This is my message";
var message = new Message(Encoding.UTF8.GetBytes(messageBody));
await _queueClient.SendAsync(message);
await _myOtherService.FailPotentially(); // if this method fails then message will ne rolled back
scope.Complete();
}
catch (Exception exception)
{
scope.Dispose();
_logger.LogError(" ... ", exception);
throw;
}
Based on ServiceBus documentation you must use standard pricing instad of basic