hi all,
imo we should first exactly define the purpose of the 2nd level cache before we can decide which types to cache.
if the 2nd level cache is mainly used to increase performance then i think caching of lobs etc. does not make sense. what do we cache if an object has lob-fields ? all other fields, or do we not cache the whole object at all ?
if the 2nd level cache is used to optimize sql-updates we should store as many types as possible.
just my 0.02 chf
jakob
Brian McCallister schrieb:
On Mar 10, 2005, at 3:57 PM, Armin Waibel wrote:
The basic problem is how can we make an image or a copy of a persistent object, how to copy the object fields?
On OJB java-field-type level a field (of a persistent class) could be all kind of class, because the user can declare a field-conversion in the field-descriptor, thus we don't know the field type in the persistent object.
So it's not possible to image/copy field values on this level, because the fields don't have to implement Serializeable or Cloneable.
Backwards incompatible option: provide a copy function on field conversions. Provide an AbstractFieldConversion which keeps a flat fieldwise copy of the custom object, but can be replaced by a more intelligent version. I like this option less than the next...
If we convert the fields to the sql-field-type using the javaToSql field-conversion we know the type of the field (performance issue when using complex field-conversions?), because this is declared in the field-descriptor and we are using the jdbc type / java type mapping of the JDBC specification:
VARCHAR --> String
VARBINARY --> byte[]
DATE --> Date
Caching the jdbc type makes the most sense to me, and going ahead and doing the conversion. I don't think the second level cache should be keeping entity instances around, just the sql values. Running them through the conversion process is still much cheaper than hitting the db.
...
Now we know the type of the field. All possible types, FieldType implementation classes, are defined in the new class metadata.FieldTypeClasses as static inner classes.
We differ two base types:
- Immutable, like String, Integer, Long,...
- Mutable, like Date, Timestamp, byte[],...
To copy immutable types is easy, use the field value itself. Problematic are mutable types (copy values, compare values) and mutable types that behave like immutable types, because we can't handle them (like Blob, Clob, Struct,...).
How should we handle these "exotic" types?
For Date and its ilk, and arrays, providing special handling for them is reasonable. Arrays of immutables will be a pain, but then so is caching of LOB's (should we even cache LOB's?)
-Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
