Sequential numbers without a database?

Hi all,

I'd building an app that posts to a web service. One of the things
that is required in the soap header is a sequential number appended to
a ref, i.e. "IGI1001", "IGI1002", etc.

Obviously the first part of the reference ("IGI") stays the same, but
I need an incrementing number generated. Now, I was thinking of doing
this via a SQL database, but it would be an awful waste as there would
only be one table and one stored procedure in it. Then I was thinking
of putting it in an application variable: it would be read from a file
at the application start, incremented through the life of the
application, then written back to the file at application end. I
quickly discounted that in case the new number didn't get written back
to the file for whatever reason.

Incidentally, the web service expects the caller to provide the
incrementing alpha-numeric reference, so it won't be done at the web
service.

Any thoughts?

Kind regards,

Mike KingscottHallo Mike
"Mike Kingscott" <mike@.kingscott.f9.co.uk> schrieb im Newsbeitrag
news:7d9b584d.0407010225.3365dc16@.posting.google.c om...
> Hi all,
> I'd building an app that posts to a web service. One of the things
> that is required in the soap header is a sequential number appended to
> a ref, i.e. "IGI1001", "IGI1002", etc.
> Obviously the first part of the reference ("IGI") stays the same, but
> I need an incrementing number generated. Now, I was thinking of doing
> this via a SQL database, but it would be an awful waste as there would
> only be one table and one stored procedure in it. Then I was thinking
> of putting it in an application variable: it would be read from a file
> at the application start, incremented through the life of the
> application, then written back to the file at application end. I
> quickly discounted that in case the new number didn't get written back
> to the file for whatever reason.
> Incidentally, the web service expects the caller to provide the
> incrementing alpha-numeric reference, so it won't be done at the web
> service.
> Any thoughts?
> Kind regards,
> Mike Kingscott

I think, wether it is a waste, to use a sql database. its the safest way to
ensure there is always an incremented number.

regards benni
Any chance you could use a timestamp, or a GUID in the headers to make
them unique? Or does it absolutely have to be a sequential number?

Perhaps you could use a combination of incremented number and a
TimeStamp. The TimeStamp could be the time at which the application
started, say with DateTime.Now.Ticks. The sequential ID could then be
a static field that you increment with the Interlocked.Increment
method.

Possible?

--
Scott
http://www.OdeToCode.com

On 1 Jul 2004 03:25:58 -0700, mike@.kingscott.f9.co.uk (Mike Kingscott)
wrote:

>Hi all,
>I'd building an app that posts to a web service. One of the things
>that is required in the soap header is a sequential number appended to
>a ref, i.e. "IGI1001", "IGI1002", etc.
>Obviously the first part of the reference ("IGI") stays the same, but
>I need an incrementing number generated. Now, I was thinking of doing
>this via a SQL database, but it would be an awful waste as there would
>only be one table and one stored procedure in it. Then I was thinking
>of putting it in an application variable: it would be read from a file
>at the application start, incremented through the life of the
>application, then written back to the file at application end. I
>quickly discounted that in case the new number didn't get written back
>to the file for whatever reason.
>Incidentally, the web service expects the caller to provide the
>incrementing alpha-numeric reference, so it won't be done at the web
>service.
>Any thoughts?
>Kind regards,
>Mike Kingscott

Sequential one request at a time processing

ASP.NET processes one request at a time, sequentially. If one process
blocks or sleeps then it brings down the entire application for all
users.

This fact is hidden under the rug by Microsoft. It would clearly be a
problem for any website that has tons of traffic.

On this I seek specifics.

Is it sequential per DLL or per page? If one page blocks, on say a big
database query, will other pages process and respond?

On a multi-processor server, say with four processors, is this still a
problem? Or will each processor be independent of eachother?

How does this sequential processing scale to a web farm or garden?

Thanks for your help.asp.net does not process pages sequential, it can currenlty process as many
requests as the thread pool size. if your pages are processing sequentialy,
then you have put code on your pages that blocks.

-- bruce (sqlwork.com)

"Bruce W.1" <no@.direct.email> wrote in message
news:4023BDDA.57A8DAAF@.direct.email...
> ASP.NET processes one request at a time, sequentially. If one process
> blocks or sleeps then it brings down the entire application for all
> users.
> This fact is hidden under the rug by Microsoft. It would clearly be a
> problem for any website that has tons of traffic.
> On this I seek specifics.
> Is it sequential per DLL or per page? If one page blocks, on say a big
> database query, will other pages process and respond?
> On a multi-processor server, say with four processors, is this still a
> problem? Or will each processor be independent of eachother?
> How does this sequential processing scale to a web farm or garden?
> Thanks for your help.
bruce barker wrote:
> asp.net does not process pages sequential, it can currenlty process as many
> requests as the thread pool size. if your pages are processing sequentialy,
> then you have put code on your pages that blocks.
> -- bruce (sqlwork.com)
================================================== ======

Wrong. Test it yourself.

When a page blocks, for whatever reason, other requests to the page are
not processed.

Sequential numbers without a database?

Hi all,
I'd building an app that posts to a web service. One of the things
that is required in the soap header is a sequential number appended to
a ref, i.e. "IGI1001", "IGI1002", etc.
Obviously the first part of the reference ("IGI") stays the same, but
I need an incrementing number generated. Now, I was thinking of doing
this via a SQL database, but it would be an awful waste as there would
only be one table and one stored procedure in it. Then I was thinking
of putting it in an application variable: it would be read from a file
at the application start, incremented through the life of the
application, then written back to the file at application end. I
quickly discounted that in case the new number didn't get written back
to the file for whatever reason.
Incidentally, the web service expects the caller to provide the
incrementing alpha-numeric reference, so it won't be done at the web
service.
Any thoughts?
Kind regards,
Mike KingscottHallo Mike
"Mike Kingscott" <mike@.kingscott.f9.co.uk> schrieb im Newsbeitrag
news:7d9b584d.0407010225.3365dc16@.posting.google.com...
> Hi all,
> I'd building an app that posts to a web service. One of the things
> that is required in the soap header is a sequential number appended to
> a ref, i.e. "IGI1001", "IGI1002", etc.
> Obviously the first part of the reference ("IGI") stays the same, but
> I need an incrementing number generated. Now, I was thinking of doing
> this via a SQL database, but it would be an awful waste as there would
> only be one table and one stored procedure in it. Then I was thinking
> of putting it in an application variable: it would be read from a file
> at the application start, incremented through the life of the
> application, then written back to the file at application end. I
> quickly discounted that in case the new number didn't get written back
> to the file for whatever reason.
> Incidentally, the web service expects the caller to provide the
> incrementing alpha-numeric reference, so it won't be done at the web
> service.
> Any thoughts?
> Kind regards,
> Mike Kingscott
I think, wether it is a waste, to use a sql database. its the safest way to
ensure there is always an incremented number.
regards benni
Any chance you could use a timestamp, or a GUID in the headers to make
them unique? Or does it absolutely have to be a sequential number?
Perhaps you could use a combination of incremented number and a
TimeStamp. The TimeStamp could be the time at which the application
started, say with DateTime.Now.Ticks. The sequential ID could then be
a static field that you increment with the Interlocked.Increment
method.
Possible?
Scott
http://www.OdeToCode.com
On 1 Jul 2004 03:25:58 -0700, mike@.kingscott.f9.co.uk (Mike Kingscott)
wrote:

>Hi all,
>I'd building an app that posts to a web service. One of the things
>that is required in the soap header is a sequential number appended to
>a ref, i.e. "IGI1001", "IGI1002", etc.
>Obviously the first part of the reference ("IGI") stays the same, but
>I need an incrementing number generated. Now, I was thinking of doing
>this via a SQL database, but it would be an awful waste as there would
>only be one table and one stored procedure in it. Then I was thinking
>of putting it in an application variable: it would be read from a file
>at the application start, incremented through the life of the
>application, then written back to the file at application end. I
>quickly discounted that in case the new number didn't get written back
>to the file for whatever reason.
>Incidentally, the web service expects the caller to provide the
>incrementing alpha-numeric reference, so it won't be done at the web
>service.
>Any thoughts?
>Kind regards,
>Mike Kingscott