Hi Ben,
I do a lot of processing like this. I like to use the Execute on server
property for the method doing the processing. The structure is pretty
straightforward:
// EOSmethod ( parameters ) -> text
// first off, check the semaphore
If (Not(Semaphore("specialMethod")))
READ ONLY(*) // put the tables you need in read write
// -- do the work
CLEAR SEMAPHORE("specialMethod")
Else
$errMsg:="Sorry, another user is running this method."
End if
$0:=$errMsg
It's really a good idea to use an object at the parameter. You can return
results in that object too. To do so you want to pass a pointer to the
object. (That's not necessary when you pass an object on the client
machine.)
To accomplish the part about returning control to the user while this runs
you want to hand it off to a separate process on the client. This could be
done with a method like this:
// run_EOSmethod (parameters{;longint})
Case of
:(Count parameters=1) // called to start the process
// only allow one instance of this per client
$pid:=Process number("run_EOSmethod")
If($pid=0) // not running on this client
$pid:=New process("run_EOSmethod";0;"run_EOSmethod";$1;Current process)
else
ALERT("The method is already running!")
end if
:(Count parameters=2) // this is running in a separate process
// now we have a new process on the client
$errMsg:=EOSmethod($1)
-- do something with the $errMsg is necessary --
End case
I like this scheme because it's easy to setup and debug. The
"run_EOSmethod" is basically the launching method. You can see how passing
parameters in an object would give you a lot of flexibility.
It sounds like you've read up about EOS but a couple of things work keeping
in mind:
the method runs on the server in the 'twin' of the calling process
the twin has it's own current record, current selection and variables which
aren't shared with the client (includes IP vars)
be sure to unload any records accessed in the EOS method
This last point can be hard to figure out because Locked attributes tells
you who has the record locked but not whether it's locked on the client or
server in an EOS twin of a process.
On Fri, Nov 9, 2018 at 9:40 AM Ben Sokal via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> Hello,
>
> Hoping someone can point me in the right direction as I've never done
> something like this before.
>
> We have a multi-user environment running v16r5. Through various means, a
> user can call a method that updates company-specific financial data. The
> problem is that it can take 30+ seconds and the user is left waiting until
> this finishes. What we want to do is this:
>
> - Return control to the user while the task runs in the background. We
> want the task to run on the server instead of on the client machine like
> it's currently doing.
> - If this user or a different user runs the task again for the same
> company, we need to queue it up somehow and do this after the previous
> processing finishes. If this user or a different user runs the task for a
> different company, we could either do the server processing at the same
> time since there's no data conflict, or queue it up if there is a risk of
> trying to do too many things at once.
>
> I've read the language manual and understand the syntax of semaphores,
> which is what I'm thinking I need to use (but am not completely sure).
> Beyond the syntax of commands, I don't know how to implement this. For
> example if I'm doing an "execute on server", is the semaphore going to be
> set on the client side before we call the server to run its method, or is
> it the server method that does the semaphore? Is this going to be a local
> semaphore or global? There are transactions involved in the actual
> processing...does this impact at all how I need to go about doing this?
>
> Thanks for any tips!
> Ben
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
> **********************************************************************
--
Kirk Brooks
San Francisco, CA
=======================
*We go vote - they go home*
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
