Replicating the "master" database creates a strange phenomenon on Replicate ASE

[former_member350489]

We're running MSA replication on ten user databases and also replicate the master database.

PDS->PRS->RRS->RDS

What we can see on the RDS is that users that for example has changed their password on PDS, is replicated to RDS as they should.

The transaction(s) however is not removed from the RDS/ASE process list. They just stay there doing nothing and has a status of "commit transaction".

And as you probably know, if you replicate the master database, a "maintenance user" is NOT used to do the work/transaction on your RDS like when you replicate a normal user database. It is the actual user that is logged on to the PDS/ASE that is also logging on to the RDS/ASE and execute the same stored procedure there.

This means that on our RDS, the number of active connections continues to grow, even if these connections has completed their processing.

What we also can see, is that if the RDS/ASE is restarted, all these connections/processes are removed.

But from my point of view, all these replicated transactions should terminate and be removed by themselves, and not remain as active in the process list ?

Does anyone recognize this phenomenon and/or have any solution for it ?

Thanks

/Mike

[terry_penna]

Hi Mike

Can I get some more details from you?

1) What version of RS and ASE are you running?

2) Want to verify that you are just using master database replication as defined in the RS administration guide to replicate user information?

3) Does this situation happen just when they are changing their password?

If that is the case are they changing their password because it has expired?

If it is the case that it is expired does it expire at the sametime on the replicate ASE?

Regards

Terry

[former_member350489]

Hi Terry

Answers to your questions;

1) We run on ASE Version 15.7.0 EBF 20953 ESD#4.2 and RS Version 15.7.1 EBF 21463 SP102, both on Linux 64-bit

2) Yes, everything is set up "by the book" !

3) I actually don't know that, but that is what we have found out so far and can reproduce the problem with (a password change)

In most cases that is the case, that their password has expired. But in my last test I changed my own password that hadn't expired yet and my "session" is still on the RDS.

Regards

Mike