There appear to be at least two general approaches for sequence generation both of which use the same backing table, UP_SEQUENCE. This can send confusing messages to new adopters of the portal concerning which should be used and can cause similar confusion when traditional developers are maintaining code. These really should be rolled into one with the other deprecated -OR- to avoid breaking channels that may have been designed using the deprecated one the deprecated one can be changed to delegate to the other.

The two approaches are:

[1] org.jasig.portal.services.SequenceGenerator

This class looks in portal.properties for "org.jasig.portal.SequenceGeneratorFactory.implementation"
which by default points to "org.jasig.portal.ReferenceSequenceGeneratorFactory" which implements ISequenceGeneratorFactory and returns an instance of org.jasig.portal.ReferenceSequenceGenerator which implements ISequenceGenerator. All instances of SequenceGenerator then wraps the implementation delegates all instance methods to the ReferenceSequenceGenerator singleton instance..

SequenceGenerator is referenced from these locations:
- org.jasig.portal.concurrency.caching.ReferenceInvalidatingEntityCache
- org.jasig.portal.groups.RDBMEntityGroupStore
- org.jasig.portal.tools.dbloader.DataHandler


[2] org.jasig.portal.utils.CounterStoreFactory

This class looks in portal.properties for "org.jasig.portal.utils.CounterStoreFactory.implementation"
which by default points to "org.jasig.portal.utils.RDBMCounterStore" which implements ICounterStore. The CounterStoreFactory instantiates a singleton instance of RDBMCounterStore and returns for all calls made to getCounterStoreImpl().

CounterStoreFactory is referenced from these locations:
- RDBMUserLayoutStore
- RDBMChannelRegistryStore
- RDBMPortletPreferencesStore
- RDBMUserIdentityStore