public void addToDirtyList(final GPO gpo){
  if (gpo == null)   throw new IllegalArgumentException();
  if (!gpo.isDirty())   throw new IllegalStateException();
  m_dirtyGPOs.add(gpo);
  if (m_dirtyGPOs.size() > m_maxDirtyListSize) {
    if (log.isTraceEnabled())     log.trace("Incremental flush of dirty objects");
    flushDirtyObjects();
  }
}

public void addToDirtyList ( final GPO gpo ) { if ( gpo == null ) throw new IllegalArgumentException ( ) ; if ( ! gpo . isDirty ( ) ) throw new IllegalStateException ( ) ; m_dirtyGPOs . add ( gpo ) ; if ( m_dirtyGPOs . size ( ) > m_maxDirtyListSize ) { if ( log . isTraceEnabled ( ) ) log . trace ( "Incremental flush of dirty objects" ) ; flushDirtyObjects ( ) ; } }
gpos are added to the dirty list when initially modified . the dirty list is not bounded . large updates should be done using the rdf and sparql layer which do not have this implicit scaling limit . < p > note : we can not do incremental eviction unless we are holding open a connection to the database that will isolate those edits . this could be done in principle with either full read / write transactions or with the unisolated connection ( if embedded ) but we do not yet support remove create / run / commit for full read / write transactions in the nss rest api . the problem with holding the unisolated connection across incremental updates is that it will lock out any other updates against the backing store for the life cycle of the object manager .
