|
[
Permlink
| « Hide
]
Clinton Begin added a comment - 17/Feb/05 01:04 PM
Thanks for the submission. You can attach the code to this JIRA request.
Since EHCache requires Serializable value object, our real value object gets disassembled into Serializable components and back at retrieval.
There is a slight Springframework dependency (Assembler). But can be easily implemented on your own and changed for usage (see TypeFactory). Removed Spring dependency - unsing DefaultAssembler in DefaultTypeFactory.
Developers using iBatis with Spring are recommended to use SpringAssembler. My preference here is to remove the Spring dependency and resolve it in some other fashion. None of our other caches have the need to hook into Spring. Being that i have used Spring with iBatis with no need for placing Spring in the internals of iBatis I have a strong sense of unease doing it here. I feel as though it would bring an unwelcome presidence into the mix. If we provide Spring hooks then others might feel then need to have [name your favorite IoC container here] hooks. Unless there are some significant objections, I am going to rework this to be more like the other Caches and leave the Spring integration to Spring. I am also not keen on the use of System.getProperty for setting the TypeFactory implemetation. That should be set elsewhere (a config setting in iBatis). I think we can take this contribution and rework it to provide Ales with what he needs and keep Spring out of iBatis as well. Thoughts?
I'm wondering if we should expand the use of "settings" in the sqlmap config. Maybe allow it to have a <property name="..." value="..."/> similar to our pool configurations. This would allow for the setting of arbitrary global properties so that things like the ehcache can have it's own TypeFactory specified (for Spring usage). The settings can be looked up during parsing and set in the CacheModel.
For example <settings [...]> <property name="CacheModel.ehCacheTypeFactory" value="my.custom.typefactory.for.ehcache.MyClass"/> </settings> The cacheModel could have a Map on it that stores anything with the "CacheModel." in it. Anything that has the CacheModel available to it would also have any global values set in the sql-map-config in the <settings><property/></settings> tag. Further thoughts? Additionally, you can programatically on the fly configure each cache within the cacheManager. I'm thinking we should add the ability to configure your cache within ibatis like all the other caches. Again we can provide the option of an externally configured cache via a setting property. However, I think for most iBatis users who want to take advantage of ehcache they would prefer to have their cache configuration within ibatis.
Good idea, let's do that. <cacheModel> already supports <property> though. CacheModel supports property, true. But, is there a current way to specify global properties shared across all CacheModels?
After thinking about it a bit. Maybe it would be more appropriate to add a new tag to the sqlMapConfig called <globalCacheModel> that only has <property> tags contained within it. That allows us to avoid the annoying "CacheModel." parsing on <setting> properties. All i'll have to do is add a new Nodelet and a few other things. Then I can pass the property reference from the globalCacheModel into the individual CacheModels. If we agree on this... i'll go to it.
ex. ---- sql-map-config.xml ---- ... <globalCacheModel> <property name="ehcacheConfigXml" value="com/foo/ehcache/config.xml"/> <property name="typeFactory" value="com.foo.ehcache.MyTypeFactory"/> </globalCacheModel> ... Something else we need (should be opened in another ticket) is code to allow complete custom implementations of CacheModel. Similar to how we allow TagHandler or TagHandlerCallback, we need to allow both CacheModel and CacheController to be implemented. Some more advanced caching systems will require lower level control that only a custom CacheModel can provide.
Cheers, Clinton Customer CacheModels will be a good thing. Should we still move ahead with the <globalCacheModel> approach?
"Since EHCache requires Serializable value object, our real value object gets disassembled into Serializable components and back at retrieval."
The assemble/dissasemble is pretty cool stuff. But, i'm not sure it is something we want in the iBatis framework. --- The ehcache FAQ states --- Can non-Serializable objects be stored in a cache? No. Both keys and values must be Serializable. The reason is they must be Serializable to be persisted to the DiskStore. If the type was Object and not Serializable, runtime UnserializableExceptions would be thrown when an Element is transferred to the DiskStore. As it is now, your keys and values must be Serializable or you will get a compile-time error. --- end --- I think this is the responsibility of the developer to mark their classes as serializable. I'd prefer to remove the assemble/disassemble functionality from the ehcache impl. Perhaps we can provide a hook to allow this kind of customized behavior when we make the CacheModel more flexible. Thoughts? " My preference here is to remove the Spring dependency and resolve it in some other fashion."
--> As stated: "Removed Spring dependency - unsing DefaultAssembler in DefaultTypeFactory." Regarding assemble/disassemble, I wouldn't remove that from EHCache impl. Since iBatis doesn't require Serializable domain objects, it's the job of CacheController to provide a way to use cache properly. I'm on a project in which we're trying to integerate EHCache with iBATIS. I saw this patch was attached to this quite some time ago but hasn't been integrated into iBATIS yet. Does this mean the patch does not work?
I'm also very interested in this.
Please, any update ? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
EHCache for iBatis
