Re: blocking other instances from activity
Re: blocking other instances from activity
- Subject: Re: blocking other instances from activity
- From: OC <email@hidden>
- Date: Fri, 06 Mar 2015 12:24:50 +0100
Thanks!
That would be probably the best solution -- especially since all the “special” activities I at the moment can think of are triggered by the state of the objects in DB, i.e., I would not even need the requests.
Actually I have suggested this approach at the very beginning, but alas, the client for some reasons of his “strongly prefers, if possible” (he said) that the app is self-containted and does not need other helper applications (myself, I guess the reason probably would be the simplicity of deployment and administration of the deployment sites).
Well on the other hand, the client pays for my work, so it's all right :)
All the best,
OC
On 5. 3. 2015, at 18:34, Chuck Hill <email@hidden> wrote:
> What I have done is to have another app that processes this type of activity and the main app just writes a “request” into a table that the processing app polls. So any number of users can submit requests for processing and have them accepted, but they are only processed sequentially, with an email or other notification when completed.
>
> Chuck
>
>
> On 2015-03-05, 9:15 AM, "OC" wrote:
>
> Hello there,
>
> there are some activities of my application which should do only one instance (e.g., archivation of objects). At the moment, I intend to
>
> (a) add to my DB a specific table, say, T_LOCK; its rows would contain (at least) ACTIVITY_ID (PK or at least UNIQUE), USER_NAME, and TIME_STAMP;
> (b) when an instance is about to start an activity, it would first insert a new row into that table
> - if it fails, it would fetch the current row for given ACTIVITY_ID and would log (or, if interactive, say to the user): "Sorry pal, but USER_NAME started this at TIME_STAMP, so we do nothing at the moment; try later"
> - if it suceeds, it would start the activity and when done, delete the row.
>
> Plus I guess I will have to add a possibility for some highly trusted administrator user to display the whole table and to delete any of its rows, in case e.g., the instance which did the activity crashed before deleting its lock.
>
> Since this seems to be pretty ubiquitous task for any multi-instance app, I'd be grateful for comments from all of you who unlike me do multi-instance for years: is this a good idea, or should I try to find another solution? Am I overlooking something which would in a couple of weeks or months raise its ugly head and bite me in the tender parts?
>
> Thanks a lot,
> OC
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden