Managing a process over prolonged periods of time

[solas]

I'm creating an auction website. Auctions can run for up to 30 minutes...

So it seems, I need process running for each auction for the duration of the auction to update bids etc...

I have 2 solutions so far:
1) Run a cron job every 5 mins to see if an auction should start.
If so create and instance of the Auction manager that will exist for the duration (up to 30 mins).
2) Run a cron every minute that will update the auction details and refresh the auction room.

The first seems more logical and less programatically intensive... Both however require dedicated servers and I had hoped to start off on a VPS.

Does anyone have any ideas of how to get around this? It seems like it may well be impossible to track something that lasts 30 minutes on a server where you can only run a script for 30 seconds.

Do my approaches sound reasonable or does anyone have any better suggestions?

[Dan Grossman]

Auction sites like eBay and the SitePoint Marketplace don't involve any processes running longer than it takes to respond to a page request.

Each page (list of auctions, single auction, etc) is generated the moment it is requested by a browser using data in the database. They're not statically generated by some background process to be served up in the future.

Things that are conditional, like whether an auction is currently open or closed to decide whether the bidding form should be displayed, are decided at the time of the request by looking at the start/end times recorded for that auction in the database when it was created.

Unless you're creating something totally different in nature than these websites, you don't need to worry about managing any long running processes.

[solas]

Hi, my needs are slightly different than these ebay and the market place.

I believe I have 2 options.

1) Involves a process that runs for the duration of the auction.
2) Involves doing it at run time as you suggest ebay etc do.

I definitely don't have experience of running background processes like this though.

Is there issues involved with running background processes that would make them something to be weary of? For example if I have 100 auctions running at the same time that would mean 100 processes each running for up to 30 minutes.

[Dan Grossman]

It would be interesting to hear why you believe you need that.

One problem you're going to have is how the web server is going to interact with these processes. Someone visits your site to view an auction, how is that HTTP request connected to the process you spawned for that auction?

[solas]

I have to take care what I say, but the main reason I feel I need it is because:

1) the details of the auction will be changing regularly over the life time of the auction perhaps every minute.

also

2) it seems more logical to my mind to have a background process over the life time, rather than having to rely on http requests to make the changes to the auction details that I have to make.

I don't understand why eBay and Sitepoint don't do the same and that's why I'm concerned about hidden complexity.

Are they waiting for a person to bid, then updating the db with latest price and then updating people's screens with new price via ajax?

The background process will update the database record related to that auction.

The http request by a user will interact with that database record.

My main problem at the moment is how do I create say 10 processes (auctions) that run simultaineously.

If I loop through the database of auctions to see if I need to launch a process, it will only produce the process one after the other, where as I need them to launch simultaineously...if you know what I mean.

[Dan Grossman]

Are they waiting for a person to bid, then updating the db with latest price and then updating people's screens with new price via ajax?

Yes, the current auction price is only updated when someone bids.

Why else would the record have to change except when a user makes an HTTP request from their browser by clicking a link or submitting a form?

Nobody's screens are updated until they refresh, but you could easily refresh it for them with a periodic AJAX request.

I get the feeling you see an auction having a start and end time as a reason to have some process to manage it. You don't need any such process. The start and end time are recorded in the database. You don't need to do anything at the start time, or at the end time. The HTTP request to view an auction can look at the end time and not display the auction if the current time is greater than the auction's end time. The HTTP request to make a bid can look at the record to see if the bid is greater than the current high bid and that the current time is not greater than the auction's end time. There is no need for something existing separately from the HTTP request/response loop.

[solas]

Hi Dan, this isn't exactly the same thing. I have sent you a pm.

[sk89q]

I think you need to be clear as to what you need to occur (1) when an auction opens and (2) when an auction closes.

[maznaz]

There is nothing in the description you've given to indicate that a management task running every minute to flag auctions as closed won't be sufficient, if you intend to offer any live (ajax supplied) data to the end user.

If your application is stateless for the user, and completely HTTP page request oriented, you don't even need that periodic task, as already said. You just need to check statuses before you return the page.

[solas]

Hi Guys, I'm a little shy on mentioning too much as I'm working on this for a client and can't give too much away.

Dan has given me a hand via PM (thank Dan) and I have a solution I'm happy to proceed with for now...

Thanks