[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Messages posted by: gluck  XML
Profile for gluck -> Messages posted by gluck [178] Go to Page: 1, 2, 3  ...  10, 11, 12 Next 
Author Message
Hi, Infrastructure somehow missed it. It got pushed to oss.sonatype.org a few hours ago and should now be in maven central.
You can just use cache.put() and put the byte array in. Or you can create a value object to describe the type, file size etc.
Hi Adam.

We actually have a reseller based out of Sydney who have a team of Terracotta experts. The company name is Ecetera.

Their number is (02) 8307-3890.

Greg Luck
CTO
Yeah we have talked about doing this ourselves to do better with evicted element selection.

We haven't added any metadata for something like an int being creationExpense however there is a field might be able to be reused.

Use the version. There is little using it. It is just a long and you can easily make it mean expense. You could even just add a timer for the time to create the element from the underlying resource in ms and store that there. Then create a custom evictor that uses it.

Version can be set at Element construction time or afterwards with the setVersion(long value) method.

There is one smallish problem depending on your use case. If a cache element gets updated i.e. the cache already has it and you do a put then the version field gets updated with the update timestamp. Why? It seemed like a good idea at the time.

This is the code that does it. See cache.put()

if (elementExists) {
element.updateUpdateStatistics();
}
The put signature is being changed in JSR107 to void put(K key, V value);

This will get done in Ehcache's implementation next year.
So by alias you mean that the username is keyed by both name and userid but it is the same entry.

We don't support that but a nice abstraction you can use it a Cache decorator except backed by two caches not the normal one.

You can also in the second cache have userid => username to save space and then have username => full details in the second which should save space.

You can also declare the cache searchable. So you would make userid a search attribute.
We search against a single cache. I would create in effect a denormalised view and put that in the cache. You then use Ehcache's search feature to perform quite rich searches including the types you gave as examples. You create searchable attributes by configuring AttributeExtractors. See the docs.

Seeing as you never want to hit the database you therefore need the entire dataset in cache.

In terms of loading new data into the cache you can do that in batch or continuously. The CacheExtension interface is a nice place to do this. You will need to implement a timer, either something simple or you could use Quartz as Karthik suggests, and execute your database queries. If running in batch it might be better to pick a quite time at night when the database is not heavily used.
End of October
(Also answered your personal email)

Have you used the ExplicitLocking API? We designed it for just this purpose. See http://ehcache.org/documentation/explicitlocking.html

This does not need any TIMs, just Ehcache and Terracotta. It is built in to the download of Ehcache.
The cache is passed in on the notify methods. Maybe get it from there. But you have to create your own listener so you could also store a reference to the cache.

Yes, removeAll is network optimised. You could always iterate through the collection and call remove on the same class to get non-optimised behaviour.
You would want to use the a single ehcache.xml and use CacheManager as a singleton.

I suggest placing the ehcache.xml in the same location as the war so that you have only one.
Hi

There is a difference between the open source and enterprise ehcache. The former keeps keys in memory when they are stored on disk. 140 million will probably consume too much heap.

The enterprise ehcache store stores the keys on disk.

Corruptions are not known to occur in normal operation, only on OS or JVM crashes. You should set your diskStore to persistent so it comes up again when you restart normally.
My fault. I was playing around with JSR107 config and generated the site by mistake. Fixed now.
Yep, there are two editions. An OSS version and a Commercial version with extra features and support.
I think you will need to create an ehcache.xml, do the replication there and then use EhCacheManagerFactoryBean in Spring to wire it into the application context.

See http://static.springsource.org/spring/docs/3.1.0.M1/javadoc-api/org/springframework/cache/ehcache/EhCacheManagerFactoryBean.html
 
Profile for gluck -> Messages posted by gluck [178] Go to Page: 1, 2, 3  ...  10, 11, 12 Next 
Go to:   
Powered by JForum 2.1.7 © JForum Team