public interface ServerDataSourceImplementation
Bear in mind the following points when working with DataSources (whether custom or built-in) on the Smart GWT Server:
Spring-injected dataSources, note that the
default scope for a Spring bean is "singleton". This means that a single instance of the bean
is cached by Spring and returned every time the framework code asks for that DataSource. This
pattern prevents the Smart GWT framework from making the above-mentioned guarantee that no
single instance will be used by multiple threads, and can lead to unpleasant concurrency bugs.
The solution is to mark your Spring beans with a scope of "prototype" (you could also use
"request", but Smart GWT caches DataSource instances per-HttpServletRequest anyway, so nothing
is gained by doing that). See the
Spring documentation for further information about bean scope.
non-transactional operations on the same DataSource instance in a single HTTP request can lead
to connection leaks if you are using the built-in Hibernate or JPA DataSource.
datasource.cacheFailedLookups is set, the server remembers the names of
DataSources it failed to look up, and does not attempt to look them up again (until the server
is restarted). This provides a negligible performance improvement in normal circumstances,
but can provide a more significant benefit in cases of questionable usage where DataSources or
field types are declared server-side, for use purely client-side. Note, if you set this flag, a
DataSource that you introduce in the middle of a running application will not be picked up if
the system has already cached a failed lookup of that DataSource.
datasources.pool.enabled is set, DataSource instances are automatically cached in
an in-memory pool. This caching is smart: if the underlying
.ds.xml file changes,
cached instances are discarded and rebuilt.
.ds.xml file) is read the first time the DataSource is
requested; thereafter, we will only re-read the configuration file if its last-changed
timestamp changes. This scheme combines the performance benefits of caching with the with the
convenience of being able to change a
.ds.xml file and pick up the changes
without restarting the server.
RPCManager.getDataSource(). If pooling is enabled, this is the only way to
obtain a DataSource instance with the guarantee that it will be returned to the pool at the
end of request processing.
provide DataSources to the framework dynamically:
DataSource.fromXML() APIs to construct your DataSources from an XML document
or String of XML text
new DataSource(), as this will introduce thread-safety issues
DynamicDSGenerator, pooling is inappropriate because the returned DataSource for a
given name might be different each time the generator is called. For this reason, pooling of
dynamic DataSources is disabled by default. To enable pooling for dynamically-generated
DataSources, set the
datasources.poolDynamicDataSources to true. Keep in mind, that if pooling for
dynamic DataSources is enabled, then DataSource definition must be the same for the same
DataSource ID. NOTE: Here, "dynamic DataSource" means a DataSource whose name would cause the
framework to invoke a DynamicDSGenerator, which doesn't necessarily mean that the generator
would actually create a dynamic DataSource. As the server-side documentation for
DynamicDSGenerator.getDataSource() states, a generator can simply return null to
decline the opportunity to create a dynamic DataSource. Therefore, if the proper operation of
pooling is important to you, avoid patterns of
DynamicDSGenerator usage that
involve registering more generically than you need to. In particular, avoid the
addDynamicDSGenerator() signature that does not take a prefix or regex parameter
- this will cause the pooling subsystem to regard all DataSources as dynamic, and will
effectively disable all DataSource pooling.