TIBCO Activespaces – Best Practices – 7. API Considerations
Many ActiveSpaces API objects are thread safe (meaning that multiple threads can use them at the same time)
- The Metaspace object is thread safe:
- Metaspace connection is actually a process-wide resource.
- Use getMetaspace() to get more copies of the metaspace object as needed.
- Space objects are thread safe:
- Multiple threads can use the same space object at the same time.
- Operations by multiple threads on the same Space object are parallelized. This is a very efficient way to increase throughput!
- Browser objects (used for queries and iteration) are thread safe: you can have more than one thread calling the next() method of a single browser object
Java/.NET Specific Things to Remember
- Remember to always stop your browsers when you are finished with them.
- There are resources associated with a browser (possibly including a new thread) that will not be garbage collected if you don’t call stop().
- Since you have to try/catch creating and using the browser, the final statement, for example, would be a good place to do it.
- Remember to keep a reference to your space object, if it gets garbage collected, your listeners and browsers will stop working!
- The best way to do this is to remember call close() at the end of the part of the code for each corresponding getSpace() calls.
- Multiple calls to getSpace() will return reference counted copies of the Space object that is created by the first getSpace() (or browse() or metaspace.listen()) call, those copies could be garbage collected at different times and therefore cause a process to go from seeder to leach on the space.
C-Specific Things to Remember
- You can pass NULL as the oldValue parameter to your put/putEx calls
- You can pass NULL as a filter string.
If you use shared-nothing persistence, you MUST ensure that your seeders all have a specified member name, and that this member name is consistent from one instance of the seeder to another over time.
While ActiveSpaces does support deployments in virtual environments, it does so only when the following conditions are met:
- TCP discovery only:
- Some virtualized environments do not support multicasting (notably public clouds).
- Even in virtual environments supporting multicasting, our experience is that those environments do not do a very good job of it (lots of packets drops).
- No VMWare snapshots:
- “Snapshots” in VMWare can result in TCP connections being dropped (and if the snapshots last long enough in timeouts), which means processes being kicked from the metaspace when the snapshot is happening.