I am wondering if anyone had attempted to run two concurrent pro4 servers against the one oracle database.
The reason I am asking this is that I can see benefit in load balancing our pro4 users across two servers with two independent code sets that have been mirrored.
Limiting the impact against a hardware failure
Better batch processing capabilities
Greater processing capabilities.
Click the link below to see the new game I'm developing!
Two Pro4 Servers accessing One DB?
Started by
Guest_Guest_sleezy_*
, Jul 06 2006 05:58 AM
4 replies to this topic
#2
Wim Soutendijk
-
- Members
-
- 216 posts
ProIV Guru
- Gender:Male
- Location:Netherlands
Posted 06 July 2006 - 06:27 AM
We are running on 2 Windows pro-iv servers and one SQL database server for a number of years without any problems.
The only thing you have to consider is that @TERM will hold a unique value per pro-iv server, but the two servers might give you the same @TERM value. To overcome this problem, our logon screen adds a 1 or a 2 (depending on if started up from server 1 or server 2) to @TERM, to make it unique again. We use a lot of workfiles keyed on @TERM.
The only thing you have to consider is that @TERM will hold a unique value per pro-iv server, but the two servers might give you the same @TERM value. To overcome this problem, our logon screen adds a 1 or a 2 (depending on if started up from server 1 or server 2) to @TERM, to make it unique again. We use a lot of workfiles keyed on @TERM.
#3
mdexter
-
- Members
-
- 70 posts
Advanced
- Gender:Male
Posted 06 July 2006 - 04:52 PM
I would assume in this scenario you would need to keep ALL permanent data in SQL tables (as opposed to PRO-ISAM), including things like next available sequence number or invoice number. If so, do you have issues with SQL holding locks on these tables? We've had to move this type of next sequence number back to PRO-ISAM to get around the transaction / locking issue.
Have you run into this? If so, how do you handle it? Thanks. Mark Dexter
Have you run into this? If so, how do you handle it? Thanks. Mark Dexter
#4
Guest_Guest_sleezy_*
Guest_Guest_sleezy_*
-
- Guests
Posted 07 July 2006 - 01:55 AM
Thanks Gentlemen
Its on a UNIX Solaris site that is transitioning from proISAM to Oracle DB.
You've give me some hope! I guess I now need to test for my environment before re-writing the code to handle multiple environments.
Its on a UNIX Solaris site that is transitioning from proISAM to Oracle DB.
You've give me some hope! I guess I now need to test for my environment before re-writing the code to handle multiple environments.
#5
Wim Soutendijk
-
- Members
-
- 216 posts
ProIV Guru
- Gender:Male
- Location:Netherlands
Posted 07 July 2006 - 06:27 AM
Yes, we have to store everything in the database, we don't use pro-isam at all.
It does generate record locks. The mosty used workaround is that the start function of a transaction will update the counter, do a COMMIT(), and start with the data entry screen. If the user cancels, the counter is lost.
It does generate record locks. The mosty used workaround is that the start function of a transaction will update the counter, do a COMMIT(), and start with the data entry screen. If the user cancels, the counter is lost.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
Click the link below to see the new game I'm developing!
