Special replication requirement

[sdjensen]

I have two databases which needs to be in syncronization with each other and I need read/write access on both of them at the same time.

What is the best solution for this setup?

 

[MaximMonin]

progress doesnt support 2way replication.
You have to write replication-create, replication-write, replication-delete triggers
log changes, transfer it to second db and import changes on second db.

 

[sdjensen]

I was hoping I could do it in Progress but it does not seems to be possible.

Thanks for your input.

 

[tamhas]

Recognize that 2 way replication is a very, very hard problem. I doubt that anybody does it out of the box with a simple configuration. The DataExtend product from PSC ... which unfortunately does not yet support OpenEdge databases ... has a kind of solution which works across different database types and schemas, but its focus is a long way from total replication. It is more directed at something like having two versions of a customer table in different applications and wanting to keep those parts which correspond in sync. Even that is a very hard problem. There was another DataExtend product, which I don't know if they still make, which addressed the problem of two databases that had some overlap and which were either connected most of the time, but unreliably, or connected only rarely (e.g., a salesperson's laptop), but again careful configuration was required and lots of rules about which end took precedence for which information and error reporting when something didn't work. Trying to keep two identical databases in sync while both are undergoing changes is certain to fail and do so very quickly, leading to lots of manual caretaking.

So, what is the real world problem you are trying to solve here. Tell us that and we may have some suggestions.

 

[sdjensen]

Thanks for your reply Tamhas.

I have a java frontend which connects through some appservers to one login server and one database where the users login and password are checked. The server logs the date and time and some other pc identification for this session in the database to be able to ensure that one userid is only used from one pc at a time.
Once the users has been validated the requests are forwarded to other servers where their data is stored.

This works perfect today but we are getting more and more customers to the system and we need to make sure that our system is up and running 24/365 and that is why I would like to add another login server where the database is the same as the other login database.

When a user changes his password and other settings it will be stored in the login database so it needs to replicated to the other server pretty fast ;-)

If one login server goes offline the users should not notice it because the other server should be able to handle the requests.

I hope this gives an idea of what I am trying to do.

 

[tamhas]

From that description, I can see the need for conventional replication so that you have a hot spare and, of course, after imaging to make sure that you preserve all changes, but I have trouble seeing a login database as a bottleneck. Isn't their interaction with the login database just one nearly instantaneous transaction? What are they doing with the application ... just twiddling their thumbs?

I don't think it addresses your concerns specifically, but you might want to look into the client-principle object as a way to manage security. We will have a session on it at PUG Challenge Americas.