TERRACOTTA *
- Hibernate
...
- cache raw compenent types, no objects
...
- 1st level cache (tied to db connection, goes away when db connection
goes away)
- 1st level cache (tied to db connection, goes away when db connection
...
- 2nd level cache (avoid going back to db, pluggable, ehcache most
common, terracotta another option)
- 2nd level cache (avoid going back to db, pluggable, ehcache most
...
- needs to be across cluster for writing data
...
- ehcache
...
- option for clusterwide Hibernate 2nd cache
...
- uPortal boxes all have to talk to eachother, get 5-10 becomes
...
- problem, exponentially chatty
...
- Terracotta (open source)
...
- option for clusterwide Hibernate 2nd cache
- option for clusterwide Hibernate 2nd cache
...
- could use it directly as well
...
- advantages
...
- in clustering,
...
- shardingÂ
- separate service, not run on uPortal boxes
- shardingÂ
...
- less "chatty", all uPortal boxes talk to same terracotta box, this
allows "sharding" (see below)
- less "chatty", all uPortal boxes talk to same terracotta box, this
...
- keeps data as Hibernate 2nd level objects (however those are done),
...
- like a shared memory for all uPortal boxes, "network attached memory" (like
...
- NAS for memory)
...
- mark a particular part of application object as "distributed"
...
- could be called an object oriented db, persists all of its cache to disk
...
- data persists until orphaned, then its garbage collection
...
- use to cluster Tomcat http sessions
- use to cluster Tomcat http sessions
...
- does it better that Tomcat own session clustering for same
"chattiness" issue
- does it better that Tomcat own session clustering for same
...
- still doesn't get around serializable requirement, but has config
...
- option in case you can't serialize in Java code
...
- Big Savings: "sharding", only possible with terracotta's less-chatty architecture,
...
- terracotta will only push one box's cache to other boxes when other
...
- boxes look for it
- ? should people worry about clustering with uPortal?
...
- Cris doesn't see big value to clustering http options, e.g. Madison
...
- only gets 1.7 requests per login, little chance for failover there
...
- important for Sakai, e.g. things go boom in the middle of an exam
...
- UofC will be in between
...
- uPortal, 2nd level Hibernate cache for layout
...
- trend in uPortal has been that session cache is becoming more
...
- serializable
...
- Stuff going on
...
- Sakai
- Sakai
...
- Cris used in Sakai instance for John Wiley&Son, will be part of
Sakai 2.7 (code freeze Nov. 20 to meet late Winter/early Spring release)
- Cris used in Sakai instance for John Wiley&Son, will be part of
...
- capabilities will be in Sakai, up to implementers to turn it on
...
- with it on you should be able to fail over without having to log back in
...
- for app specific things, e.g. an exam, you can terracotta-enable
...
- tool by tool, some tools don't have much state and don't need it
...
- Hibernate 2nd level thing is huge
- Hibernate 2nd level thing is huge
...
- uPortal session is possibility, Eric has been thinking about it
...
- Cris interested in finding uPortal instance where big gains can be
...
- made with terracotta
...
- sidenote: there is a way to plug terracotta behind an ehcache
...
- terracotta can be used without Hibernate, use configs to cache
...
- without app even knowing (good and bad)
- without app even knowing (good and bad)
...
- "super static" - local static class attr, cluster in terracotta
...
- config, now static across cluster, not just local JVM
...
- Webinar on changes made to Sakai October 29th 10:30 am pacific
...
- possible alternative to db, does data really need to be in a db? e.g. Sakai
...
- "presence" data
...
- questions? Talk to Cris, also the Terracotta guys are very accessible