Multithreading

[Jupiter]

[FONT=&quot]Version: Progress 9.1D[/FONT]
[FONT=&quot]Platform: Windows 2000 Server[/FONT]
[FONT=&quot] [/FONT]
[FONT=&quot]My billing application has a client DB connected in single user mode and also connected to a server. The requirement is the client should get synchronized with the server as the Client application is loaded. But the synchronization process should run in the background, so that the user can start working just after loading the application.[/FONT]
[FONT=&quot] [/FONT]
[FONT=&quot]How can this situation be tackled?
Thanks in advance.[/FONT]

 

[joey.jeremiah]

[FONT=&quot]Version: Progress 9.1D[/FONT]
[FONT=&quot]Platform: Windows 2000 Server[/FONT]

[FONT=&quot]My billing application has a client DB connected in single user mode and also connected to a server. The requirement is the client should get synchronized with the server as the Client application is loaded. But the synchronization process should run in the background, so that the user can start working just after loading the application.[/FONT]

[FONT=&quot]How can this situation be tackled? [/FONT]
[FONT=&quot]Thanks in advance.[/FONT]

you could start the clients personal db in multi-user mode and have a separate process (batch session) running in the background that syncs with the central database at set intervals and whenever possible.

of course the sync agent would only be a single part of the overall replications scheme and the complexity highly depends on the replication model or what places can update.

 

[tamhas]

http://oehive.org/MultiThread

 

[joey.jeremiah]

Very interesting article ! Have there been any responses from Progress ?

It's likely multithreading will make a comeback as one of the must have hot buzzwords with processor improvements going towards multicores, and eventually is going to be the main way to keep getting substantial processing performance improvements.

5 years from now we are all going to have quad core 64bit running on our desktops, it will be unfortunate if we can only take advantage of one with Progress.

 

[tamhas]

Have there been any responses from Progress ?

Yes, but don't hold your breath. It is clear that this would require some highly non-trivial changes in the AVM and, at this point, I don't get the sense that anyone on the inside thinks this is as important as I think it is.

Consequently, I am doing a lot of thinking about way in which multiple sessions can communicate in a way that imitates multithreading.

 

[Jupiter]

For Ref:
[FONT=&quot]Version: Progress 9.1D[/FONT]
[FONT=&quot]Platform: Windows 2000 Server

[/FONT]Thanks to Joey and Tamhas.

Hopefully we'll have some cool features for handling such issues from Progress in near future.

But I am still looking for the best solution.

I have around 30-40 client machines. In each machine my billing application runs. It connects the local db in single user mode and the server (which is of course running in multi-user mode). I cannot run each of the 30 Point-Of-Sale machines in server mode (multi-user mode, with a service) because my setup will become complicated and difficult to maintain.

[FONT=&quot]Few Words About My Billing Application[/FONT]
There is an interface where barcodes are scanned. Those barcodes are validated against some master tables. On server everyday new master data records are created or updated. So synchronization of the master data is required with the Point-Of-Sales on daily basis.

So for successful background synchronization I am looking for some technique that will allow me to start two independent processes from the same session (as I am connected to the Local DB in single user mode). One GUI based process will keep my scanning operation process functional and the other process will do the job of synchronization.

How can this be done? Please suggest.

 

[joey.jeremiah]

it would make no difference what so ever and you would not need to make any changes to the code if you're running a personal database in multiuser mode.

you can write a short script (with some 4gl code) that is run before a session starts that starts the database if it is not already running. and another script when leaving a session that shuts down the database if there are no other connections (the application or sync agent).

a one way replication scheme is something that's relatively practical to write and there are plenty of solid implementations, though, it may have some challenges with a large number of replication sites.

bottom line is i don't think you have alot of options to choose from. you could either replicate the changes synchronously when the application loads and continue after it has finished or run the database in multiuser mode and have another session handle synchronization with the central database.

 

[tamhas]

As much as I would like to see multi-threading, I don't think your situation is a compelling case. Really, you have two basic choices. One is to do your synchronization at specified off hour times; the other is to have two processes. The latter will require the local database to be multi-user, but really this is not a big deal. It is easy to create scripts which will start the database automatically.

 

[joey.jeremiah]

As much as I would like to see multi-threading, I don't think your situation is a compelling case. Really, you have two basic choices. One is to do your synchronization at specified off hour times; the other is to have two processes. The latter will require the local database to be multi-user, but really this is not a big deal. It is easy to create scripts which will start the database automatically.

I think in this case we're not dealing with servers, they're mostly disconnected private laptops and I'm not sure synchronizing in off hours may be practical or can be counted on.

 

[tamhas]

Well, for syncing frequently disconnected devices and/or periodically disconnected devices, I don't think you will find a neater technology than DataXtend ... when they get around to making it available for Progress and assuming that the price is not astronomical.

But, baring that grand and glorious future, I still think that the problem decomposes into one of two different scenarios depending on the business context. In one scenario there is a need for a once a day loading of tables or the like and one incorporates this into the workflow. In the other scenario, the updates need to be semi-continuous and then one needs to put the database into multi-user mode and have two processes.

 

[joey.jeremiah]

Well, for syncing frequently disconnected devices and/or periodically disconnected devices, I don't think you will find a neater technology than DataXtend ... when they get around to making it available for Progress and assuming that the price is not astronomical.

I'm sorry if it comes off rude but it is really not intended at you Thomas.

DataXtend is turning out into, for lack of a better word, sad joke.

And it's likely the same case for the other Progress companies supporting OpenEdge, it feels like they're just not interested. So I wouldn't hold my breath for all the other great gadgets. I think we should just stop fooling ourselves.

If you look up "OpenEdge" in the DataXtend knowledge base you'll get back 3 results (for every DataXtend product) -

DataXtend RE 8.1 will not support the OpenEdge 10 database

There is no plan at this point to have DataXtend CE work with Progress OpenEdge

DataXtend Enterprise 8.1 will not support the OpenEdge 10 database

I know, they've talked about it here and there (even way back when it was still called PeerDirect) ... so they said, they say alot of things.

 

[tamhas]

It was promised, not discussed, at last year's conference. Remember too that there are two different products, RE and CE and the one that would be useful here is RE. I will see if I can remember to ask for an update at the partner's meeting next week.

 

[joey.jeremiah]

That would be really interesting to know !!!

I would love to be wrong.

 

[tamhas]

I think there is a lot of this that will happen ... eventually ... but that doesn't mean that people won't get tired of waiting!

 

[FrancoisL]

For your problem you can simulate multi-Threading with the command PROCESS-EVENTS. if you design your sync procedure around this , you should be able to continue processing the scanner while sending data.

You need to put the PROCESS-EVENTS in each of your large Transaction . What will PROCESS-EVENTS do is that it will permit pending events to execute each time it see the PROCESS-EVENTS command. So it not true multi-Threading but it will permit your transfer of data without blocking your sales application.

Example :

FOR EACH <ExportTable> :
/** Your code here **/

PROCESS-EVENTS.
END.


So at each iteration of your FOR EACH you will be checking for events and allow other code to run .

 

[lord_icon]

[FONT=&quot]Version: Progress 9.1D[/FONT]
[FONT=&quot]Platform: Windows 2000 Server[/FONT]

[FONT=&quot]My billing application has a client DB connected in single user mode and also connected to a server. The requirement is the client should get synchronized with the server as the Client application is loaded. But the synchronization process should run in the background, so that the user can start working just after loading the application.[/FONT]

[FONT=&quot]How can this situation be tackled? [/FONT]
[FONT=&quot]Thanks in advance.[/FONT]

Run the update procedure persistent.
That were the basis for ADM(1). Objectize ,where each entity (object / procedure) is simply an object within the process. By executing PERSISTENT it will allow Progress to execute other processes. Example syntax would be RUN procedureNameToSyncData PERSISTENT hSetHandleVar /*assign the process a handle can reference later*/
DO:
/* process you wish to executen */
END.

 

[tamhas]

Persistence does not create a separate execution thread.