REST API begin transaction (do stuff) end transaction?

[Zack Morris]

Hi I’m working on push notifications in javascript. The final code will probably go in either a Parse or node.js server somewhere. I realized that for tasks like this, it would be nice to be able to follow the pattern that php/mysql typically uses for sending emails:

begin database transaction
save email details in database
send email
end database transaction

Or to clean up automatically in case of unexpected errors or exceptions:

with database transaction
{
save email details in database
send email
}

That way if anything goes wrong, the user can always try again by resubmitting the form or whatever.

So my question is, is there a way to do something similar in Firebase? I realize there are transactions in the SDK but I’m trying to do this purely through the REST API. I stumbled onto this:

http://stackoverflow.com/a/23068147

I’m thinking that this may be possible by using a node kind of like a mutex or semaphore, by setting a flag to indicate the server is busy, then clearing it when the server is done. There are problems with this approach though if the connection drops. The mutex would need to be reset after a timeout period. I would prefer to do it in a lockless (atomic) manner.

One way that might work is to set up a queue node for the server, and only allow adding children if the update_counter in the request is equal to the old update_counter + 1. So users could submit jobs on the work queue and the server would watch for them and do what’s requested. This would probably require getting javascript to only run one task at a time somehow, even if users are making multiple simultaneous requests. Otherwise we’d have multiple readers and be back to figuring out how to isolate their transactions again. The nice thing though is that I could take advantage of the SDK’s transaction functions when the users post jobs to the queue. The only catch there is that the users are technically untrustworthy, so this should have to work safely whether they use transactions or not, the way the stack overflow answer above works.

Anyway, it helped to write this but I’m worried that I’m making it overly complicated. Anyone know if there’s a way to implement begin/end transaction on a node or two?

Thanks for any help you can provide,

Zack Morris

[Zack Morris]

> On Mar 7, 2015, at 6:52 PM, Zack Morris <zmo...@gmail.com> wrote:
>
> Hi I’m working on push notifications in javascript. The final code will probably go in either a Parse or node.js server somewhere. I realized that for tasks like this, it would be nice to be able to follow the pattern that php/mysql typically uses for sending emails:
>
> begin database transaction
> save email details in database
> send email
> end database transaction
>
> Or to clean up automatically in case of unexpected errors or exceptions:
>
> with database transaction
> {
> save email details in database
> send email
> }
>
> That way if anything goes wrong, the user can always try again by resubmitting the form or whatever.
>
> So my question is, is there a way to do something similar in Firebase? I realize there are transactions in the SDK but I’m trying to do this purely through the REST API. I stumbled onto this:
>
> http://stackoverflow.com/a/23068147

I was thinking through the logic of this and had some questions. Say the node is at 10 and two users try to write 11 to it. Will only one user receive a success response, while the other receives a permissions error? I assume that’s the case.

What about with timestamps, if a user writes the kFirebaseServerValueTimestamp value of {'.sv': 'timestamp’}, and the write rule is:

.write: newData.val() != data.val() && newData.val() === now

And both users happen to write within the same millisecond, so the old value was 10000 and the new value is 12345, will one of them be successful while the other receives a permissions error? Or will they both receive a response containing the new timestamp?

Thanks,

Zack Morris

[Michael Lehenbauer]

Hey Zack,

Sorry for the super slow delay, but yes.  In the scenario you described (both write at the same timestamp, that rule would fail, since we'll execute the writes one at a time, and so the 2nd one will be overwriting with the same value and newData.val() will equal data.val().

Hope this helps.

Thanks,

-Michael

Zack Morris

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4A4FC124-C4AE-4EA0-995C-D26660B7B679%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Zack Morris]

> On Mar 20, 2015, at 10:50 AM, Michael Lehenbauer <mic...@firebase.com> wrote:
>
> Hey Zack,
>
> Sorry for the super slow delay, but yes. In the scenario you described (both write at the same timestamp, that rule would fail, since we'll execute the writes one at a time, and so the 2nd one will be overwriting with the same value and newData.val() will equal data.val().
>
> Hope this helps.
>
> Thanks,
> -Michael

Hey no worries, thanks, that’s good to hear :-)

Zack Morris