You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bogien <bo...@icpnet.pl> on 2005/11/14 14:01:39 UTC

Holding SelectionModels in the Global object, invalidating them?

Hello,

Please tell me if this is a good approach...

In my web application, I have many comboboxes (<select>),
holding constant sets of values. These sets are represented by
Tapestry's IPropertySelectionModels. I hold their instances
in my SelectionModelPool object and initialize them lazily
when needed. The SelectionModelPool object is held in
the Global object, so there could be less reads from the database:


   public abstract class SomePage
   {
     public IPropertySelectionModel getCountriesSelectionModel()
     {
       return getGlobal().getSelectionModelPool().get("countries");
     }

     /* ... */
   }


   public class SelectionModelPool
   {
     private Map pool = new Hashmap();

     public IPropertySelectionModel get(String name)
     {
       if (pool.get(name) == null)
       {
         // fetch the data from the database
         // create an instance of IPropertySelectionModel
         // insert it into "pool" map
       }
       return pool.get(name);
     }

     /* ... */
   }



Is it OK?

What if I'd like to force SelectioModelPool refresh
by issuing sth like "getGlobal().getSelectionModelPool().pool.clear()"
- will it work?

Thanks for any help!



.

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


RE: Holding SelectionModels in the Global object, invalidating them?

Posted by Patrick Casey <pa...@adelphia.net>.
	I use a similar approach (pooling my select models) and haven't had
any problems. Just make sure your selectmodel implementations are themselves
thread-safe (because you can't guarantee atomicity of access).
	Likewise there's no synchronization I can see on access to your pool
object which may (or may not) be an issue depending on the thread safety of
the underlying collection.

	If you're using hibernate by the way, you've already got a rock
solid cache entity (ehcache) installed, which you can use for your own
caching as well as Hibernate's caching which may save you having to write
your own cache/pool entity. I know that the novelty wore off the third or
fourth system I had to implement a scavenging LRU cache so I'm always happy
to use somebody elses implementation these days :).


	--- Pat

> -----Original Message-----
> From: Bogien [mailto:bogien@icpnet.pl]
> Sent: Monday, November 14, 2005 5:02 AM
> To: Tapestry users
> Subject: Holding SelectionModels in the Global object, invalidating them?
> 
> Hello,
> 
> Please tell me if this is a good approach...
> 
> In my web application, I have many comboboxes (<select>),
> holding constant sets of values. These sets are represented by
> Tapestry's IPropertySelectionModels. I hold their instances
> in my SelectionModelPool object and initialize them lazily
> when needed. The SelectionModelPool object is held in
> the Global object, so there could be less reads from the database:
> 
> 
>    public abstract class SomePage
>    {
>      public IPropertySelectionModel getCountriesSelectionModel()
>      {
>        return getGlobal().getSelectionModelPool().get("countries");
>      }
> 
>      /* ... */
>    }
> 
> 
>    public class SelectionModelPool
>    {
>      private Map pool = new Hashmap();
> 
>      public IPropertySelectionModel get(String name)
>      {
>        if (pool.get(name) == null)
>        {
>          // fetch the data from the database
>          // create an instance of IPropertySelectionModel
>          // insert it into "pool" map
>        }
>        return pool.get(name);
>      }
> 
>      /* ... */
>    }
> 
> 
> 
> Is it OK?
> 
> What if I'd like to force SelectioModelPool refresh
> by issuing sth like "getGlobal().getSelectionModelPool().pool.clear()"
> - will it work?
> 
> Thanks for any help!
> 
> 
> 
> .
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org