rawi wrote:
>
> Leo Mannhart wrote:
>> Caveat: If you use the standard sequence generator in hibernate, it is
>> not using the postgres-sequence in the "usual" manner. hibernate itself
>> caches 50 ID's as sequence numbers by default. This means, hibernate
>> only does a select on the database sequence every 50 numbers. it
>> multyplies the database sequence by 50 to get the "real" sequence
>> number. it generates the sequence numbers in blocks of 50 numbers or
>> according to the sequence cache size.
>> That said, you would probably not see any performance bottlenecks
>> because of the sequence number generator in the database, even with
>> thousands of inserts per second.
>>
>
> Hi Leo, thank you for the explanation!
>
> I don't know if it is that cool to lose up to 50 IDs on each session-end of
> Hibernate...
What you mean "loose 50 IDs"? Sequences are never meant to be gap-free
therefore you are not "loosing" IDs at all. OTOH are you saying, that
one session is just inserting one row and then disconnects from the
database? Then it would be somewhat a waste to use hibernate and all
this caching mechanism, but I highly doubt this. Isn't your app running
on a middle tier and hibernate will only be shutdown when the app server
will shut down? Then there is no "loosing" of IDs either.
> And what do you suppose it would happen, if I set the cache size of
> Hibernate's own sequence (after generation) by hand to 1 instead of 50? I
> wouldn't need tausends of inserts per second...
Why should you do that? You want to know, how much is the network
roundtrip adding to the response time? Just let it how it is; it is a
good starting point.
>
> Kind regards, Rawi
>
