RE: [Springframework-developer] DataFieldMaxValueIncrementer

[Dmitriy K. <dko...@ru...>]

+1 for removing cache from sequence-based incrementers

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, February 26, 2004 2:43 AM
To: spr...@li...;
spr...@li...
Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer


Actually, MySQLMaxValueIncrementer does leverage the value cache in a
meaningful way, and HsqlMaxValueIncrementer at least just issues a =
single
delete for the entire advance cache. But the sequence-based =
incrementers,
i.e. OracleSequenceMaxValueIncrementer and the new
PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
cache at
all. So I just suggest to remove the value cache from the sequence-based
incrementers.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 26.02.2004 08:25
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer



I'm done with the simplicication so far - less than half of the code =
remains
;-)

However, there's still the value cache. I strongly doubt that this is a =
good
idea, particularly with database sequences. Essentially, if the cache =
size
is 10, we're accessing the sequence 10 times in advance instead of =
asking in
whenever an id is requested. There's the same amount of SQL statements
involved; what's the benefit here?

The drawback is that we need to synchronize cache access for this. If we
simply went straight to the database sequence for each id, we could =
delegate
concurrency to the database. And I don't know of an O/R mapping tool =
that
does such sequence value caching (please correct me if I'm wrong). All
things considered, I suggest to drop the value cache completely.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
tri...@tr...
Gesendet: Mi 25.02.2004 23:02
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




+1

I never understood the need for a double as an incrementer anyway.  =
Simple
is better.  The OracleSequenceMaxValueIncrementer could use some =
refactoring
too. We don't need a SqlFunction - we should be able to use the new
queryForXxxx methods on the JDBC Template.  Once you check in your =
changes,
I can take a look at the Oracle one.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =

> =3D our JIRA. On the occasion, I've reviewed the incrementer =3D
> implementations: They're too complicated for what they achieve, =3D=20
> IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =

> =3D the code to the DataFieldMaxValueIncrementer class hierarchy =
itself.=20
> =3D20 I've noticed that AbstractDataFieldMaxValueIncrementer's=20
> nextDoubleValue =3D effectively returns an integer, like=20
> nextIntValue/nextLongValue - after =3D all, the template method=20
> getNextKey returns a long, so there's no chance =3D for a true double. =

> Thus, I see no point in keeping the nextDoubleValue =3D method in the=20
> DataFieldMaxValueIncrementer interface; all current =3D =
implementations=20
> do not return doubles here. =3D20
> Furthermore, why does getNextKey take a type parameter when it returns =
a =3D
> long anyway? Any JDBC driver will let you read both an int and a long =
=3D
> via rs.getLong, so there's no point in that type parameter. Simply =3D
> reading the value via getLong should be sufficient.
> =3D20
> This leaves a very simple DataFieldMaxValueIncrementer interface with =
=3D
> nextIntValue, nextLongValue and nextStringValue methods, with =3D
> implementations that achieve their goal in a straightforward fashion. =
=3D
> AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
=3D
> which returns a long, casting the long to an int respectively =
converting =3D
> it to a string with optional padding.
> =3D20
> This should still cover all current usages and therefore not break =3D
> compatibility, and it should make it as easy as possible to implement =
an =3D
> AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
=3D
> Thomas, Dmitrity, what do you think?
> =3D20
> Juergen
> =3D20
> P.S.:
> Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
=3D
> the week. I believe it's worth it, as I'd also like to wait for =
feedback =3D
> on the other recent changes.
> =3D20
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and=20
> deploy apps & Web services for Linux with a free DVD software kit from =

> IBM. Click Now! =
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer