I'm wondering how grails handles memory usage and loading (fetching) of domain objects by GORM methods like:
findAllWhere
findAllBy
list
...
Are they fully loaded (respectively their proxies) into memory?
If I traverse them with each/every/any are they backed by an iterator loading them lazily?
Should I prefer createCriteria() {...}.scroll() for better memory usage?
Assuming that we ignore the different behavior of each type of DB driver GORM uses, we can find the answers in the code and the documentation.
The dynamic finders are provided to Domain classes by org.grails.datastore.gorm.GormStaticApi and the finder classes within the org.grails.datastore.gorm.finders package.
Reviewing these classes we are able to see that queries which return multiple results are always assembled as a DetachedCriteria and always invoke the criteria.list() method; this means that the whole result batch is assembled and held in memory. Traversing the results with Groovy's collection methods won't make any difference because you're essentially invoking those methods on the returned result list.
As to the question "How much of the result Domain is loaded?" - this depends on the composition of the domain, but you may assume that the fields of the Domain are loaded and that any associations are by default lazy.
In scenarios that require better memory usage you can certainly self-compose the criteria in conjunction with result projections and use scroll (note that this feature depends on the type of DB).
In extreme cases I even bypass GORM and work directly with the DB driver.
Related
It happens that there are sometimes lines of code or methods that can't produce mutants that are going to be killed by any relevant test. (For instance I may be using a null pattern object, and some of the implemented methods are not relevant in prod, so any implementation (even throwing) would be correct).
It would be nice to be able to tell pit to avoid them (so that the mutation coverage is more relevant), but I couldn't find a way to do it in the documentation.
Is there a way to do it?
PIT currently has five mechanisms by which code can be filtered out.
By class, using the excludedClasses parameter
By method, using excludedMethods
Using a custom mutation filter
By adding an annotation named Generated, CoverageIgnore, or DoNotMutate with at least class level retention. (N.B javax.annotation.Generated has only source retention and will not work)
The arcmutate base extensions allow mutation to be filtered using code comments or external text files
For your use case it sounds like options 1, 4 or 5 would fit.
Option 2 only allows for a method to be filtered in all classes (this is most commonly used to prevent mutations in toString or hashcode methods).
Option 3 is a little involved, but would allow you to (for example) to filter out methods with a certain annotation.
An aside.
I don't I follow your example of the null object pattern.
A null object needs to implement all methods of an interface and it is expected that they will be called. If they were to throw this would break the pattern.
In the most common version of the pattern the methods would be empty, so there would be nothing to mutate apart from return values.
This behaviour would be worth describing with tests. If your null object fails to return whatever values are considered neutral this would cause a problem.
According to the Guice wiki page, unscoped binding is preferred to Singleton for stateless objects.
I do not agree with the statement though because:
Singleton scope gives more information to developers. Developer can assume singleton objects are thread-safe and they can be injected without using Provider most of the time.
Creating an unscoped object can be expensive because of dependencies to other unscoped objects.
Cyclic dependency of unscoped objects can only be resolved with Providers, which could lead to weird behavior.
e.g. A depends on B, B depends on Provider, and some method f() in A invokes B which invokes some method in A, then a new instance of A and B will be created each time f() is called.
When injecting a Request Scoped object into unscoped objects, it is hard to tell if you need a provider or not because the life cycle of unscoped object is unknown.
Could someone explain why is default scoped preferred to singleton scope for stateless objects?
There's one big and important reason for the preference to unscoped objects instead of singleton objects: Singleton objects can never be garbage collected, nor can the entire transitive tree of objects to which they hold references. Their construction needs to be synchronized (to prevent race conditions during creation), and then they remain in memory for the entire lifetime of the Injector.
This is particularly an issue because, in a production environment, all Guice singletons are eager regardless of whether they're bound asEagerSingleton. This means that in production your memory commitment of your singleton tree starts when the Injector is created, and often lasts until the application closes.
Using Singletons for everything may cause slower startup and larger memory requirements than judiciously choosing singletons.
Of course, if the object and its dependencies are all stateless, the memory footprint of each object is pretty light. However, if your singleton depends on an object that depends on an object that depends on a database, then that database and its memory will be required on startup and never freed.
injector ___________________TIME_________________________\
creation /
|---------------------SINGLETON-------------------------->
|----------REQUEST A------------| |---REQUEST B----->
|-UNSCOPED C-| |-UNSCOPED D-| |-UNSCOPED E-|
Scopes track roughly to the lifetime of the object, and the goal is to avoid injecting a narrower-scoped object into a wider-scoped object (say, keeping around unscoped object C, which might be relevant to request A but not request B). To do so would be a scope-widening injection.
When you refer to unscoped objects, think of them as ephemeral or disposable, and having the narrowest scope possible. This makes it particularly easy to make stateless objects unscoped, because it doesn't matter which instance you have.
Those unscoped objects are also free to inject any object in the graph without using providers, on the assumption that the unscoped object will always have the shorter lifetime compared to any other dependency you pick. By contrast, a singleton must use providers for all of its non-singleton dependencies, because it will absolutely outlive any non-singleton it depends on.
This should make it clear when you need Providers, as you allude to in #1 and #4 above.
In summary, I can only direct you back to the section you linked: Unless you have a good reason (state, expensive construction, or resource management) you should probably leave your injectors unscoped.
What would be the syntax for memoizing a service method that is side-effect free and only does lookups? Would the memo persist from session to session or would it be kindof purposeless in the web world? Are there some examples of good places to use .memoize() in a grails app?
class DetermineStuffService{
def figureThisOut(def whatever){
//look up all sorts of stuff and do some heavy side-effect free processing
return nastyHashmap
}
}
So in a controller can I somehow call DetermineStuffService.figureThisOut(someRandomObject) and take advantage of .memoize()?
One problem with this is that memoize() only works on closures. Closures are objects, so if you store one in your service, it is "state".
A better way of caching services in grails is with the Spring Cache plugin. Then to cache the result of a service method, just annotate the method with #Cacheable. It has support for multiple caches, automatically flushing, and caching controller output as well.
I have a following definition.
type
TOmniTaskDelegate = reference to procedure(const task: IOmniTask);
What type of container should I use (should be supported in D2009) to store a list of TOmniTaskDelegate instances? Currently I'm using array of TOmniTaskDelegate but I'm not really happy with that.
I would use TList<TOmniTaskDelegate>. Since this is typesafe due to the use of generics, it will correctly handle the lifetime issues of its members.
Edit: Delphi 2009 includes the generic TList<T>, I assume it's implemented using array of, just as the one in Delphi 2010. That makes the TList<T> the optimal choice! My original answer stays because it explains why array of is a great data structure and why not using it is a lot of trouble.
Your choice of array of Anonym looks very good to me because:
Anonymous methods are managed entities (implemented using interfaces). They need to be properly finalized.
The dynamic array is itself a managed type, making sure the anonymous method references are properly finalized.
Delphi 2010 generic containers are implemented using dynamic arrays, so they're up to the task. But make sure you don't grow your arrays one-by-one, grow in chunks.
If you use anything else for the implementation you'll need to take care of finalizing the references yourself. Examples:
If you use plain blocks of memory you'll need an destructor that deliberately sets each item to nil (ie: not ZeroMemory or FillChar) so the compiler gets a chance to generate finalization code.
Records are managed objects, and they could hold references to dynamic methods, but they can only hold a finite number of references, if you need more you'll need to implement a sort of linked list and then you'll need to carefully manage there life cycle.
Classes suffer all the deficiencies of records, and they add their own layer of overhead on top of that.
As I understand IoC-container is helpful in creation of application-level objects like services and factories. But domain-level objects should be created manually.
Spring's manual tells us: "Typically one does not configure fine-grained domain objects in the container, because it is usually the responsibility of DAOs and business logic to create/load domain objects."
Well. But what if my domain "fine-grained" object depends on some application-level object.
For example I have an UserViewer(User user, UserConstants constants) class.
There user is domain object which cannot be injected, but UserViewer also needs UserConstants which is high-level object injected by IoC-container.
I want to inject UserConstants from the IoC-container, but I also need a transient runtime parameter User here.
What is wrong with the design?
Thanks in advance!
UPDATE
It seems I was not precise enough with my question. What I really need is an example how to do this:
create instance of class UserViewer(User user, UserService service), where user is passed as the parameter and service is injected from IoC.
If I inject UserViewer viewer then how do I pass user to it?
If I create UserViewer viewer manually then how do I pass service to it?
there's nothing wrong with this design. you use Factories for that, which have one leg in the domain, one leg in infrastructure.
You can either write them manually, or have the container do that for you, by things like TypedFactoryFacility in Windsor.
Also when your domain objects come from persistence layer you can plug your container there to inject the services they require (NHibernate can do that).
But what if my domain "fine-grained" object depends on some application-level object?
It is precisely this that is considered bad-practice. I would say the problems could be:
There are tons of these objects, so there can be performance and memory issues.
The POJO style is that they can be used in all environments (persisted in the database, processed in business algorithms and rules, read and set in view technologies, serialized and send over the network). Injecting application-level objects in them could cause the following problems:
In your architecture, you probably have the rule that some (most) application-level objects are usable in some layers, not in others. Because all layers have access to the pojos, the rule would be violated transitively.
When serialized and rebuild in another JVM, what would be the meaning of your application-level objects. They are useless, they must be changed for the local equivalents...
Typically, the pojos that constitute your domain are self-contained. They can have access to other pojos (and many enums), that's all.
In addition to the data, they have methods that implement the details of the business rules or algorithms (remember the OO idea of grouping data and code that work on it ;-) ):
This is especially good when they have inheritance, as this allow to customize a business rule for some pojo by providing a different implementation (differing case without if or switch: remember OO? ;-) ).
Any code that requires access to application-level objects (like accessing the database) is taken out, for example to a Service or Manager. But that code stays high level, thus readable and simple, because the pojos themselves take care of the low level details (and the special cases).
After the fact, you often find out that the pojo methods get reused a lot, and composed in different ways by the Services or Managers. That's a big win on reducing duplication, the methods names provide much needed "meaning", and provide an easier access to developers that are new to a module.
For your update:
create instance of class UserViewer(User user, UserService service), where user is passed as the parameter and service is injected from IoC.
If I inject UserViewer viewer then how do I pass user to it?
If I create UserViewer viewer manually then how do I pass service to it?
In that case, you need a factory method (possibly on a Factory or Locator of yours). It could look at follow, separating the two parts:
public UserViewer createUserViewer(User user) {
UserViewer viewer = instantiateBean(UserViewer.class);
viewer.setUser(user);
return viewer;
}
private <E> E instantiateBean(Class<E> clazz) {
// call the IoC container to create and inject a bean
}