Registry Services, Cache Manager service concepts and difference with portal performance views

Portlet services concepts that might be of your interest and specially when you are tuning your portal.
I am summarizing the concepts in brief with this post

Registry service

Websphere Portal maintains information about many of portal resources in it's database.
To get the faster access of these resource information, they are being replicated into memory.
Registry service is responsible for replicating these resources from database into memory for faster access.
This replication happens periodically over a amount of time ( in seconds ) which can configured by configuring reload time property of registry service.
In a production environment we expect this type of information changes very infrequently, so we should use very long reload times for each type of data it is managing to get  better performance.
One of the portal performance tuning says, increase reload time for registry service in a production environment.

Cache manager service

Cache manager service also used to cache data but in a very wide variety in memory.
These caches are somewhat similar to the registry service maintained by the registry service.
The key difference between Registry service and cache manager service are
A) The information stored in cache manager service is more dynamic in nature as compared to the information stored in registry service.
B) Cache manager service has a limited size and new entries will be discarded when cache becomes full.

The size is not limited in registry service. This contain all entries of a specific data types.
C) For each entry in cache, expiry times are managed individually for entries managed by cache manager service.

In case of registry service, when reload time is reached for a registry, the  entries contents of that registry are reloaded.

Custom portlet service - usage and implementation

Concept:- Accessing a portlet service requires a JNDI lookup for a PortletServiceHome. To use the portlet service, you retrieve a service object from the home, cast it to the service-specific interface and invoke service methods.

Let us talk about a scenario where implementation of custom portlet service solved my use case.

I had a use case where in, i was required to create a variable and make it available globally across the portal.

In detail, i wrote my own login portlet for wps 6.1.0.1 and when user hit my portlet using url http://localhost:10040/wps/InvokePortalLogin/InvokeLoginServlet?ID=5678

here i retrieve this ID in my servlet which is part of login portlet app, and redirect to portlet using IBM's Advance generation URL helper classes.

Now i was required to store this ID in login portlet in such a location so that it should be available to all the portlet apps deployed on portal.

I achieved this by creating a custom portlet service and put this data into HashMap ( there is mapping of userid as key and ID as value in map )using service methods.

Now whichever portlets need this ID after authentication, just lookup this service and call service methods to get ID of the logged in user.

things you should have knowledge of to implement usecase similar to above are

a) basic Java, J2EE concepts and Portal concepts, specially WPS

b) Login Portlet Customization

c) URL Generation API's

d) Portlet service concept

e) Custom Portlet Service concepts