|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-03 12:41:28
|
Hi everybody,
First, thanks a lot to J=FCergen and Rod for their explanations about
transactions and AOP.
For now, starting at the start, I have to use the key-generator (I'm
using MySql with InnoDB).
In this area, I will talk about two topics. 1) the use of longs 2)
caching in the key-generator
1) LONGS
I'm wondering on general lack for the use of longs and Longs in the
framework.
For the keys, are for now available ints, doubles(?) and ints as
strings. My strategy is having a unique key-generator for the whole
database, so an id is unique in the whole database. Using ints could
suffice, but handling longs has sense.
The first thing seems to add this code in the SqlFunction class (method
extract, switch statement):
------
case Types.BIGINT :
obj =3D new Long(rs.getLong(1));
break;
------
And after adding long handling methods from DataFieldMaxValueIncrementer
(long nextLongValue()) to the different classes implementing this
interface.
So, if the team accepts this idea, I can implement this and send the
sources to Isabelle for integrating.
2) CACHING
Every need of a key makes for now a RDBMS operation, this is not
necessary. Accepting eventually a few more holes in the numbering, it
could be attractive to have an increment greater than one and having by
the way a range to serve keys without querying the database. This has a
sense if the key-generator is not created each time but is a singleton.
It request the first time the database incrementing the sequence of an
increment value done in the bean definition, saying 20. It serves this
key minus 19. The next call, it serves the key minus 18 without querying
the database. And so on, when the reserve is empty, it will query the
database for a new set. The only drawback is the loosing of pending keys
when the server stops.=20
If the default value for the increment is 1, not providing an increment
value will disable the caching and run like today. In this case, only a
memory test is performed more that for now.=20
This could improve the performance, but is clearly more useful in a per
database case as in the case of a per table key-generator.
Is this best modified on the core classes or in an extended class?
As I used this mechanism with the old i21 framework, I could also make
the job.
I'm waiting for answers to know if I can go and in which way.
Regards,
Jean-Pierre PAWLAK
|