Project and Portfolio Management Practitioners Forum
cancel

Looking for feedback on running 9.x clustered (or with multiple nodes)

Highlighted
bzdafro
Honored Contributor.

Looking for feedback on running 9.x clustered (or with multiple nodes)

We just setup our 9.12 environment with 2 servers x 2 nodes each.  I noticed that request numbers are being created out of order.   Appears each node grabs a pool of 20-30 sequences for caching.   During my testing I created the sequence of request numbers below.   Has anyone experienced this same issue?  Aside from the users seeing requests being created out of sequence, we need to keep track of all requests for audit purposes.  We are concerned how it will look to auditors if they see gaps in the sequences.  Also, if we run on a single server with 2 nodes, and we shut down a node for a few days, what will happen to the cached pool of requests?   Does it get a new pool of 20 request numbers and the old pool is abandoned (creating a gap in the request numbers)?  

 

 

Req# Creation_date
30613 05/07/2012 02:04 PM
30612 05/07/2012 01:51 PM
30582 05/04/2012 05:07 PM
30554 05/04/2012 05:06 PM
30553 05/04/2012 05:05 PM

2 REPLIES
Jim Esler
Acclaimed Contributor.

Re: Looking for feedback on running 9.x clustered (or with multiple nodes)

We first noticed this behavior when running 6.0 so this is not new behavior. In fact, this occurs even with one node. If a request is spawned, the child request is assigned an id from a different pool of numbers than the parent was.

 

We have never looked to see if numbers are lost when a node stops but that would be an easy test to run. If you need to document any requests being deleted, you could probably add a trigger to log the relevant details.

Etienne_Canaud
Outstanding Contributor.

Re: Looking for feedback on running 9.x clustered (or with multiple nodes)

As Jim said, this is not a new behavior. Request IDs, like pretty much any DB Sequence in PPM, are cached for performance purposes.

 

Unless stated otherwise, you shouldn't expect any ID in PPM to be sequential. The cache size used for most PPM Sequences is 30, and it cannot be configured.

 

Such as enhancement for sequential requests IDs in clustered PPM has already been submitted on PPM 7.5, but is not currently planned for implementation in a future PPM version.

 

The two existing workarounds are:

  • If you want to order your requests chronologically, simply order them by creation date.
  • If you want a unique and sequential identifier (and don't mind the performance impact), you can use a custom field ID, then add a on-submit type rule that selects from an oracle sequence the value of this custom ID field.