Subject Re: "Generators" via table data
Author tdtappe
Thanks for your answers so far.

Ivan wrote:
> Sounds familiar, have not you asked this about year ago ?

I don't think so. Though my memory sometimes seems to be like a sieve ;-)

> Then just use single generator for everything

That won't work. I need independent counters!

Adam wrote:
> If it is possible, I would create a naming convention for the
> generators and have your application create one generator per
> counter.
> The number of generators is finite, so you may want to confirm that
> you are not going to 'run out'.

Yes. That's something that I thought about, too. But I don't like the
idea of modifying metadata in the context of a user. This would
be the first time I had to do so in my application. And I would like
to keep the metadata the same for all the installations of my application.


I think I have to show you a little bit more of the whole picture:

The "counter thing" is used for several areas of my application. As an
example think of having invoices. The user ("application admin") can
customize the creation of invoice numbers. For instance he/she would
like to have independent counters for each year, month, week, day or
whatsoever. And/or for each department. Or for each user.
And there are still much more options.

So it's not only that once the counters are set up they are kind of
fixed. The number of counters can still grow (see example above with
time being involved)

And I already have some implementation. But it seems to have problems.
Like getting deadlocks too often. Though I retry several (30) times to
get access to the counter. And I do a random sleep after a deadlock.
But probably because the requests are not queued sometimes some of the
clients still get deadlocks. But I am not sure about the reason of
this at the moment.
One thing I notice when several clients try to generate new counter
values at the same time is that obviously counters are given back to
the client in kind of "chunks". That is to say one client generates
for example 15 new counter values in a row very quickly while the
others are waiting. I would have expected a more balanced generation
of counter values across the clients.

BTW, are there any issues (performance?) with updating a record so
many times?

--Heiko