Consider a scenario where on every client side refresh, the ACS was queried for all contracts of all templates that are visible to user (multiple actAs and readAs parties):
If a ACS re-query was always done at the start of the ledger, is there a performance difference on the ledger side vs query for all transactions and process on the client side / Is there optimizations on the ledger api side for ACS query?
Thanks
Addressing this point is one of the main uses of the HTTP-JSON API. It transforms the transactional view of a ledger into a current state based view. Underneath the hood all it does is on startup query the ACS and then keep its own state up to date based on the transaction stream.
Hey. Yes I have recreated the ability through infinispan and the ickle query Lang.
But assuming you were not monitoring the translation stream. My curiosity was if the acs query has any extra optimizations vs a regular transaction stream since the start of the ledger offset and processing each transaction.
This is something I would definitely recommend not doing, unless you foresee a use case where you need to fetch active contracts very rarely (in practical terms, if the active contract set between two queries is completely disjoint is the case in which you may gain something from querying the active contract service directly every time you need it).
I’m not sure of what you mean here, did you mean “application” rather than “ledger”? The active contract set at the “start of the ledger” is always empty.
Definitely: if you query for all transactions and process them one by one, you need to go through the entire history and resolve the active contract set one event at a time. This can be useful if you need a full historic view and access to historical active contract set snapshots (i.e. answering the question “What was the ACS at offset X?”), but generally not recommended if you only want to access the “current” active contract set.
Yes, the ActiveContractsService#GetActiveContracts RPC doesn’t go through the entire history, it’s optimized to have a performance tied to the size of the active contract set, rather than the one of the entire history of transactions.
@stefanobaghino-da what about fetching ACS based on offset? Where you are keeping track of the user’s previous queried offset and using that as the ledger start point.
I ask not to say “yes i want to do that”. But to understand the perf of ACS queries.
It depends on your requirements.
If you need a fine-grained access to per-offset active contract set snapshots I would recommend following the process I mentioned above, using the transaction service to rebuild the ledger history and index it to serve offset-based active contract set snapshots. If you need to build something that needs to be active quickly (at the expense of not having the full picture from the get go) you can consider using the active contract service to fetch a recent snapshot up to a certain offset X and perform in parallel the operations of backfilling history up until X and tailing from X to keep your secondary store up to date.
If you need a coarse-grained snapshot, perhaps with a very limited amount of overlapping contracts, fetching the active contract set from the Ledger API might be viable. I’ll let you consider pros and cons of the two approaches based on your system and your requirements.
Thanks for the details. very helpful.