I'm building a reservation system and would appreciate your thoughts on the best way to tackle this. There bookable 'slots' every day (from 7am - 1pm & 2pm - 7pm). I'm making the application in jQuery/Laravel and have already build the part which reserves the slot. The slot should be reserved for a maximum of 15 mins. After this time, if the booking has not been confirmed, then the slot should become available again.
What is the best way for me to check if the reserved spot has expired? I have a number of ideas:
1) Insert a expires_at timestamp in the database when the slot becomes reserved. Then have a cron job run every minute to see if the slot has expired. If so, change the status back to Available.
2) Alternatively have a jQuery on page timer which starts as soon as the slot is reserved. As soon as it hits 15 mins, send an ajax request to set the status back to 'Available' again.
Does anyone have any further suggestions?
Thanks
Number 2 will not be recommended solution as the slot will not be available again if the browser is closed.
Instead of a cron job, you could make it part of the query.
[show records where status is not "confirmed" and expires_at > 15 minutes old]
You would show all these records as "open" to the user.
Related
I am a newer to the IBAPI. I want to place an order in the continuous trading phase after 9:30 if the open price is good for me according to some rules. After reading the document, I plan to place order in the realtimeBar() callback function, because this function will be called every 3 seconds to receive the realtime bar data.
Is there any better solution? such as sleep 100 milliseconds, wake to check and place order?
Or register some service to receive the open auction finished trigger message?
thanks a lot
Arthur
The title isn't accurate because based on what I have found in my research there doesn't seem to be a way to make a function atomic in nodejs, but I will lay out my problem to see if you people can come up with something that I have not been able to think about.
I am trying to setup a scheduler where I can set my appointment time slots say 1 hr long each and when someone makes an appointment I want to make sure that the time slot is not taken before scheduling it.
So for example I decide that I will be working from 9 am to 2 pm with a time slot of one hour. Then my schedule would be 9-10, 10-11, 11-12, 12-1, 1-2.
An appointment will come in with a start time of 11 and end time of 12. I need to make sure that slot isn't already taken.
I am using mongodb with nodejs and restify.
I understand that in my appointments collection I can set an index on a combination of values like start time and end time, as discussed here Creating Multifield Indexes in Mongoose / MongoDB.
But if I decide to change my time slot from 1 hour to say 1.5 hours then I will have scheduling conflicts as the start time and end time of entries in the database will not match up with the new interval
Currently I have a function which checks to make sure that the new appointment will not conflict but I am not sure if it will work out well when I have multiple requests coming in. This is a nodejs and restify app so basically an api with a mongodb that it talks to, to handle appointments.
I am running it with multiple workers, so I am worried that at a certain point two requests will come in at the same time, handled by two different workers for the same time slot. When my conflict checking function executes it will return saying that the slot is open for both of them since no appointment has been made yet and then there will be a scheduling conflict.
Any ideas on how to combat this, or is there something in the way javascript executes so that I shouldn't have to worry about it this? All input will be appreciated
Thanks!
I ended up using https://github.com/Automattic/kue, to queue my requests and added another endpoint where you can check the status of your request. So when you want to make an appointment your request ends up in the job queue, and you can then periodically check the status of your request. This way only one appointment request gets processed at a time so no concurrency issues.
I see on the scheduled script deployment screen on Netsuite, the Repeat dropdown starts with a minimum of every 15 minutes. Can the interval be shortened somehow?
The interval of scheduled scripts cannot be shortened to less than 15 minutes.
What you can do is set up a Suitelet that triggers the scheduled script to start. Once you get the External URL of the Suitelet you can plug it into an external cronjob service such as https://cron-job.org and set it to run every 3 minutes.
Note that the scheduled script would be put on a queue either way so it may not start immediately after.
The answer would be No. I think they are trying to prevent choking the queue so they only allow 15mins.
I am building an open sourced nodejs powered sprinkler system which will run on the raspberry pi and work with the OpenSprinkler Pi.
I am using:
sailsjs 0.9.3
laterjs - for schedule interpretation and maths
i created an issue awhile back on bunkats repo asking for him to explain this to me.. https://github.com/bunkat/later/issues/19
The end result will be a REST api interface between rpi and whatever front-end you decide to develop for. web/mobile/cli .. etc.
The way the scheduling component will work is values will be posted to the url /programs with a zone id, name, intial status (false), and a plain text human readable schedule phrase such as: every 12 hours starting on the 6th hour before 10 minutes (06:00 & 18:00 for 10 mins).
This schedule will be parsed, and stringified and stored in db as such:
{\"schedules\":[{\"h\":[6,18],\"m_b\":[10]}],\"exceptions\":[],\"error\":-1}
The other values are cleaned and stored as they were entered.
My question is:
how should I go about finding these schedules and determining their run time/date? I've got the scheduling part, and the run time down and working (run for 10 mins). I'm struggling with the theory behind efficiently retrieving the schedules though.
My initial thought was to have a interval every 1 mins poll the db...
setInterval(function(){
//get programs from db
//iterate through programs
//enable programs which start now?
}, 60000);
But this seems kind of illogical. I suppose that when the schedule is created a setInterval or setTimeout is created with the appropriate scheduling info.. but what happens if the rpi loses power, or those could eat up a bit of memory having all of these intervals hanging out there..
how will it handle existing schedules already in the db?
open source repo
of what i have so far (not much other than the creation api/models/Programs.js) is here:
https://github.com/RelativeMedia/nodesprinkler.git
At SharePoint Saturday in Lisle, IL this weekend, Robert Bogue said there's a difference between active and running workflows. I've looked on the web, but can someone clarify?
If I can have up to millions of active workflows on the server, why can I only have 15 or so running workflows per server?
Yes, there is a difference:
"Running" Workflows are all which currently are doing something (i.e. executing an activity).
"Active" Workflows are simply all which are "running" but currently are not doing anything - e.g. waiting for OnItemChanged or DelayActivity.
The key to understand this is WorkflowEventDeliveryThrottle (here for SP2007, because the documentation for 2010 doesn't exist). The standard value for this is property is 15. That means that there are only 15 concurrent workflow which can run at the same time. After this limit is reached the workflows get queued to the OWSTimer which executes the workflows after some arbitrary time (I think the workflow timer job is set to every 5 minutes).
This Throttle can be changed by using stsadm (AFAIK Powershell doesn't work - you can change the property via code of course setting SPWebService.WorkflowEventDeliveryThrottle):
stsadm -o setproperty -pn workflow-eventdelivery-throttle -pv "20"
Now the maximum number of "running" workflows (better would be "maximum number of workflow events that can be processes simultaneously") would be 20. See some other SO post where someone plays with the parameter.
There is a nice technical blog post to understand Workflow Event Processing: About the “workflow-eventdelivery-throttle” parameter.
Similar to the throttle is the WorkflowEventDeliveryBatchSize which denotes the maximum number of workflow events that are processed in a batch.
Summary:
You can have thousands of active workflows, e.g. all waiting for the workflow item to be changed. They are not running, not finished - simply active.
There is a limited number of workflow events that can be processed at the same time (you called it "running" workflows)
You could also have thousands of running workflows, e.g. all of them might get triggered by a delay activity set to 5 minutes, but only a limited number of them is running simultaneously, the rest of them gets queued for later execution.