Collected Best Practices
Best Practice : Recycle Sessions Quickly
As mentioned previously, it is important to remember that Sessions are system resources and therefore they should be managed carefully. Always release a Session back to the system as soon as you possibly can, since this allows Facets to re-use the resources (specifically the shared memory) that the Session holds onto. In practical terms this means obtaining a session from the SessionFactory just before you need it and sending it the close() message as soon as you have finished using it. Typically the release of the session should be managed by a finally clause, to ensure that even in the event of an error it is returned to the system.
Best Practice : Make Transactions Short
The Commit Record issues discussed previously can be prevented by following some simple rules when writing code that uses transactions. Always ensure that long winded operations take place outside of a transaction. This is often quite simple, however sometimes, complex time consuming code has to be executed in a transactional manner because it has persistent side effects. If this is the case, try to factor your code into smaller pieces and wrap each of these pieces in a transaction. Doing this will ensure that Facets can integrate your changes into the repository without a Commit Record Backlog. For example, never perform operations that involve interaction with a user inside of a transaction. The amount of time a user takes to respond is an eternity for a busy Facets system and in some cases the user may never respond, which could have major negative consequences on the Facets environment. If you are interacting with an external system that might fail to respond, rather attempt to interact with that system outside of a transaction.
Best Practice : Abort Soon
It is important to remember to abort a transaction as soon as possible after it has failed, since only aborting will clear the Commit Record Backlog. In some cases you may need to examine the objects that cause the conflict, be careful when doing this because the conflict set may be very large and may take a considerable amount of time to be fetched from the repository, if this is done prior to an abort, this could also lead to a Commit Record Backlog.
Best Practice : Define Collection Variables as Interfaces rather than Concrete Types
As applications change with time the type of collection that is used to hold a collection of objects may need to change - for example, there may initially not be a requirement for concurrent access to a HashMap, but with time there arises a need to allow concurrent access to the HashMap. If the type of the instance is defined to be ScalableHashMap, it will become necessary to manually change all of the references from ScalableHashMap to CuHashMap, which could be a long winded and complex process. Rather, declare the type as the interface, such as HashMap or List, and then instantiate specific instances and store them into the abstractly typed variable. Changing the actual implementation at a later stage is merely an exercise in creating in instance of the new implementation type, populating it correctly and assigning to the abstractly typed variable.
Best Practice : Use Cu collections intelligently
Because Cu collections perform a number of complex operations transparently for the programmer they have certain overheads associated with their use., and as such they should be used only where concurrent access to collections is an absolute requirement. If in doubt ask Gemstone or your local Facets expert whether they should be used or not.