On Thu, Jan 8, 2009 at 9:35 AM, Raymond Auge <ra...@liferay.com> wrote: > On Thu, 2009-01-08 at 08:53 -0800, Nathan Bubna wrote: > >> On Thu, Jan 8, 2009 at 6:39 AM, Raymond Auge <ra...@liferay.com> wrote: >> ... >> > I do have a question of my own. How many strings in the repository is >> > too many? Or an overall size. Can they have a time-to-live? >> ... >> >> There is currently no limit besides the available memory. There's >> also no expiry for them. StringResourceRepositoryImpl just uses a >> synchronized hashmap to store StringResource instances. But >> StringResourceRepository is an interface, so fancier implementations >> are possible. > > And yet, you would really lose the performance benefit if you were to > drop them into some slower storage than memory, where you would have to > serialize them again, anyway... so that being the case... perhaps using > an LRU cache with a max size could be the solution to not killing memory > with tones of random VTL strings.
That would work great for your particular setup, where you are always checking if the resource is already stored in the repo. Others, however, may expect that strings in the repo don't disappear based on usage anymore than a lesser-used file would disappear from the file system, so that really couldn't be the default implementation. >> You would just have to set the >> string.resource.loader.repository.class property or manually set the >> repo via: >> >> StringResourceLoader.setRepository(StringResourceLoader.REPOSITORY_NAME_DEFAULT, >> myStringResourceRepo); > > Cool! > > -- > Raymond Augé > Senior Software Engineer > Liferay, Inc. > Enterprise. Open Source. For Life. > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org For additional commands, e-mail: user-h...@velocity.apache.org
