Reputation: 2189

Auto increment Id's in .net

We need to store xml file in file system. The xml files should have a uniqueId ranging from (00000001 to 99999999) Is there a way to auto increment the ids for any new xml generated. The xml are stored in folder structure which is complex. I tried taking the count of xml files that this seems to be a slow operation. The application is developed in c#.net Can anyone suggest any other way of persisting the data. Database seems to be one of the opetion but storing a value in a table with just one column doesn't sound like a great idea. can anyone suggest other ways?

Upvotes: 0

Answers (5)

John B. Lambe

Reputation: 557

There's nothing wrong with storing it in a database. It could use a table with just one record, with one (integer) field. Or other fields of the record could be used for other state of the application. (If using it with something that expects a unique key, it could have a surrogate primary key, which would just have a fixed value, e.g. always 1.) Incrementing it would be done with a transaction that reads then writes this value, and returns the new value. (So that it will return unique values if invoked concurrently.) This is probably convenient if (and only if) you already have a database.

With InterBase or FireBird, you could use a Generator (a scalar value with support for thread-safe incrementing).

Alternatively, you could store it in a file. (It could be in the same directory, named so that it can't conflict with one of the other output files.) You would open the file for writing, read it, overwrite with the new value, and close it. If two processes or threads tried to update it at the same time, one would fail with a locking error, and have to retry (thus getting the next number).

The same can be done with any other way of storing a value, e.g. your application configuration settings file, as others have suggested, or the Windows Registry (the main reason for that would be if you want it to be shared between programs potentially installed in different places on the machine, but a file in the directory of the output files also achieves this). But if it can be invoked concurrently, you have to ensure that whatever mechanism you choose handles this.

If you don't want a separate storage of the counter, and old files are never deleted, you could possibly use an optimised way of testing what the last one is, for example test for the existence of a file with the number 1 (with padding), then double this value and test again, until you find one that doesn't exist, then test the value half way between the last found one and the lowest non-existent one. Then repeatedly choose the one in the middle of the remaining possible range, until the remaining range is one value. It might be no faster, depending on how long testing existence of a file takes. And this doesn't work for concurrent access, without adding a locking mechanism (such as creating a dummy file and keeping it open, while doing this, then deleting it (and waiting if this file exists and is locked for writing)).

Of course, if the process creating the files continues running between each file creation, and is the only process creating them, you could hold the counter in memory, and only have to re-establish the value each time the process starts. (If multiple threads can create the files, you'd have to synchronize access to the counter.)

Upvotes: 0

keithwarren7

Reputation: 14278

I am assuming your application is not stateful, meaning it will be started and stopped several times.

I would consider using an Application Setting which in a standard .NET project is an option available to you that is read/write. The value can be strongly typed and will be stored in the application configuration file.

Examples: http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx

Upvotes: 5