Consider changing the ServerSideSession Id from an `int` to a `long` about identityserver

[AndersAbel]

int NOT NULL IDENTITY will max out after 2 billion sessions have been created. Do you expect to have more than 2 billion sessions (user logins)?

[TLYoz]

I have learned not expect any outcome when I don't understand the rules of the game. Since I don't know under what circumstances as session is created, persisted and the Id consumed, I cant really answer that question and was why I am asking the question here. I certainly don't expect 2 billion active sessions or indeed 2 billion individual users of the platform. But we may contemplate in the order of 10 million sessions started in a day. I don't want to make any assumptions as to what you expect the life of the session to be or whether a returning customer will pick up an expired session and refresh it. In the absence of these assumptions and being cautious of my ignorance of what the behaviour is expected to be, taking the worse case scenario that every time a new session is commenced, a new int PK is issued at a rate of upto 10 million sessions a day, then yes this could exceed 2 billion then it would last less than a year before it fell over. If I were to guess we tend to have a higher proportion of long lived sessions and the actually daily count of users is more in the realm of 2Million per day. But we have had real situations where schema has been created for other things like issued products and we have exceeded IDENTITY of Max.int. When this happens it is very stressful to fix on the fly. For this reason we tend to exercise an abundance of caution. Also some ORM implementations will allocated batches of sequential Id's where they are incrementing and not necessarily consume them all leaving gaps in the populated sequence. This rapidly consumes the capacity of this IDENTITY. As I said I am seeking some reassurance that my worse case concerns are unfounded. From: Anders Abel ***@***.***> Sent: Wednesday, July 26, 2023 12:06 PM To: DuendeSoftware/Support ***@***.***> Cc: Simon Pettman ***@***.***>; Author ***@***.***> Subject: Re: [DuendeSoftware/Support] Why is the ServerSideSession Id an `int` rather than a `long`? (Issue DuendeSoftware/IdentityServer#1387) int NOT NULL IDENTITY will max out after 2 billion sessions have been created. Do you expect to have more than 2 billion sessions (user logins)? - Reply to this email directly, view it on GitHub<#1387>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWEOCEBOWAWV6KQG5MEB7KTXSD2YHANCNFSM6AAAAAA2YMEKAA>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>> The information in this email (and any attachments) is confidential and is intended solely for the use of the individual or entity to whom it is addressed. If you received this email in error please tell us by reply email (or telephone the sender) and delete all electronic copies on your system or other copies known to you. No employee of Trainline has the authority to conclude any binding contract with a third party via email and without an explicit written consent of an authorised signatory. Trainline plc (Registered no. 11961132), Trainline.com Limited (Registered No. 3846791) are both registered in England and Wales with registered office at 3rd floor, 120 Holborn, London, EC1N 2TD and Trainline SAS (Registered No.512277450 in the Trade and Companies Register of Paris) with a registered office at 20 rue Saint-Georges, 75009, Paris.

[AndersAbel]

If you will have 10 million sessions created daily, that would indeed deplete the session store in less than one year.

We will look into it.

[AndersAbel]

@TLYoz We have looked at this and this is indeed something we overlooked in the design. We are looking into possibilities to change the Id to a long, but we need to be careful with how it would affect existing deployments.

It is also worth noting that the Id is only present on the entity we ship as part of our EF package. Internally IdentityServer uses a string key. Someone implementing their own storage layer is not affected by the int limitation.

[TLYoz]

OK. We are using your EF package. But if it is a string internally why not use a guid or are you concerned about insert performance and re-indexing.

[TLYoz]

So the other question. As it states this is enabled by default in 6.1 what steps can we take to disable it so this overrun cant occur

[TLYoz]

Also. If we run the migration script using BIGINT does anyone for see any issues with us using your underlying EF module with an Int32 in the DTO (obviously I understand the overrun) but the code will be easier to change that upgrading the table later.

[josephdecock]

OK. We are using your EF package. But if it is a string internally why not use a guid or are you concerned about insert performance and re-indexing.

That's right - our provider doesn't know which database it is being used on, but some will do a lot better with a numeric id.

[josephdecock]

So the other question. As it states this is enabled by default in 6.1 what steps can we take to disable it so this overrun cant occur

Server side sessions are only enabled if you explicitly enable them and add the services to DI. Maybe there's something incorrect or misleading elsewhere in the docs - can you point me at what you're looking at in the docs please?

[4865783a5d]

OK. We are using your EF package. But if it is a string internally why not use a guid or are you concerned about insert performance and re-indexing.

Guid's generated by EF Core's ValueGenerator cause fragmentation issues in a webfarm/with parallel inserts as those Guid's are not sequential.

dotnet/efcore#30753

[brockallen]

If/when we do this, I think it requires lots of docs around the actual DB update for systems that have no down time. Think about what the default migrations look like and how that would compare to an actual large scale system and how appropriate/inappropriate it would be. Perhaps either advice that the DBA do something to help migrate, or an example of a custom store that handles the migration record by record?

[AndersAbel]

The impact of changing the data type depends on the database engine and volume of records. Most deployments should have some less busy hours where it is possible to run a simple alter column command and change the data type.

For deployments where that would cause unacceptable downtime, the solution is dependent on the DB engine used and should be handled by a custom database migration script. For example, SQL Server Enterprise Edition has an online index rebuild feature that should allow this change to be run without interrupting access to the table.

[brockallen]

For deployments where that would cause unacceptable downtime, the solution is dependent on the DB engine used and should be handled by a custom database migration script. For example, SQL Server Enterprise Edition has an online index rebuild feature that should allow this change to be run without interrupting access to the table.

Did we open an issue then to document this?

[AndersAbel]

For deployments where that would cause unacceptable downtime, the solution is dependent on the DB engine used and should be handled by a custom database migration script. For example, SQL Server Enterprise Edition has an online index rebuild feature that should allow this change to be run without interrupting access to the table.

Did we open an issue then to document this?

I included it in DuendeSoftware/docs.duendesoftware.com#368