1

In an @future method can I persist a data at the beginning of the execution and the others at the end? Pratically, can i open and close two different transactions in the same @future method?

  • 2
    Yes. @future just runs the transaction in the future; all the normal (synchronous) capabilities of a transaction still work. – Keith C May 24 '18 at 15:13
  • 1
    A future method and any synchronous code that executes as a consequence of it executes in a single transaction. You cannot change that unless you initiate new asynchronous operations, which then execute in their own transactions. – David Reed May 24 '18 at 15:17
  • I note that the data does not persist immediately, everything persists at the exit of the method, in fact a second instance of the same method does not read the updated value but the original value. With java and mysql I could open and close an ad hoc transaction to force the immediate update of a data. if I used a static variable? Can two instances of the same @future method see the modified value of the other while it is still running? – Pericle Parquet May 24 '18 at 15:26
1

In Salesforce, there is no explicit "commit" command; everything is committed at the end or not at all (exception: Platform Events always commit). Static variables are per-transaction, so they aren't shared across different transactions, unlike some other platforms (ASP comes to mind) that means a static variable in the same way that we mean Custom Settings. The usual way to avoid this problem is to use locking statements. This is the only means that we have to explicitly force one transaction to wait while another is using the data the first needs.

1

Based on the question in comments, the answer is no, two future methods can't share data (in the sense that two unrelated transactions cannot share data) since they are separate transactions. If one asynchronous process relies on the result of another asynchronous process, you could consider turning your future methods into Queueable methods. Queueable methods can be called from other Queueable methods, so you can let one transaction finish its critical section, then start the next Queueable method (even before it has finished all of its processing).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.