One more thing.. I think you'd need to come up with a SQL query that would test for the lock using the server time and not the app server time. Basically a SELECT and INSERT/UPDATE together using CURRENT_TIME() or whatever to make sure we don't run into clock drifts.
-Elias Allen Gilliland wrote: > > > Elias Torres wrote: >> I like the proposal and I think it's very important/useful. >> >> I would suggest though to not use a hard-coded expiration mechanism and >> instead use a leasing mechanism. I propose that a task says it needs the >> lock for X number of minutes/hours and writes the time it started and >> the lease amount. It just a subtle tweak, but it optimizes the >> scheduling a bit, so a quick task like saving referrers can get a 3-min >> lease and not block 3 hours of thread time. Additionally, they could >> store the name of the task, so parallel tasks can work w/o blocking each >> other and only tasks with the same service name wait on each other. >> Obviously, a task can extend their lease if needed to run for more time. >> >> For example, let's store this as the >> property: task.indexing value: 12:00:01,3mins > > yep, I can do it that way. I guess I consider this to be the same thing > because the lease time for a given task is not likely to ever change, so > if the task knows what the lease time is for its lock then there is no > reason the lease needs to be in the db. Obviously if the lease time may > vary for a given lock then your approach makes a lot more sense. > > Either way will work, but yours is slightly more flexible so I'll do it > that way. For the actual property I am going to simplify the value so > that it's just long<time>, long<lease>. > > So if you see the lease in the db it would be > property: task.indexing value: 983472893, 1800 > > This way it's just easier for the application to use the values without > actually having to worry about parsing date strings. > > Thanks for the suggestion. > > -- Allen > > >> >> In other words, let's re-invent JINI. >> >> -Elias >> >> Allen Gilliland wrote: >>> This is a really short one, but I did a proposal anyways. I'd like to >>> add a simple locking mechanism to the various background tasks that we >>> have so that running them in clustered environments is safe from >>> synchronization issues and we can prevent a task from running at the >>> same time on multiple machines in the cluster. >>> >>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ClusteredTasksViaLocking >>> >>> >>> >>> Since this is such a short proposal I'd like to go ahead and propose a >>> vote on the proposal as is, since I don't expect there is a need for >>> lots of discussion. This would go into Roller 3.1. >>> >>> -- Allen >>> >
