There are several getXXXCount method defined in the BaseGenericObjectPool class
BaseGenericObjectPool.getBorrowedCount
BaseGenericObjectPool.getCreatedCount
BaseGenericObjectPool.getDestroyedCount
But all of them are computed since the pool was created, that is, the count is accumulated.
I would ask how to figure out the number of being borrowed objects and being idle objects the moment when user asks for these count.
BaseGenericObjectPool abstract class declares getNumIdle() method, which returns "the number of instances currently idle in the pool". BaseGenericObjectPool by itself does not provide the number of borrowed instances.
To have the number of borrowed instances you should look at classes, which implement ObjectPool or KeyedObjectPool interfaces, for example GenericObjectPool or GenericKeyedObjectPool class. These interfaces both declares the getNumActive() method, which returns "the number of instances currently borrowed from this pool" (ObjectPool case) or "the total number of instances current borrowed from this pool but not yet returned" (KeyedObjectPool case).
Related
Is possible to define a data property of a class as the number of individuals of another class, and this number is computed automatically.
There is no functionality for counting already available, far as I know.
It could be implemented for asserted axioms, but I don't think it can be guaranteed to work reliably. The open world assumption and the default non unique name assumption mean that it's impossible to say if there are unknown individuals or if any of the known individuals are sameAs each other.
I have a question:
I have a domain : LoanAccount. We have different product of loans but they just different on how to calculate the interest.
for example:
1. Regular Loan calculate interest rate using Annuity Interest Rate formula
2. Vehicle Loan calculate interest rate using Flat Interest Rate formula
3. Temporary Loan calculate interest rate with another formula (i have no idea what is that).
We also could change the rule every year ... we use different formula as well ...
My Question:
Should I put all the logic formula in services ?
Should I make every loan in different domain class ?
or should I make 1 domain class but it has different interest rate calculation methods ?
Any example would be good :)
Thank you in advance !
My suggestion is to separate interest calculating logic from the domain objects.
Hard-wiring the domain object and it's interest calculation is likely to lead you in trouble.
It would be more complicated to change the type of interest calculation for existing account type (which could be expected business request)
When new account type is created you can easily use all the calculation methods you have already implemented for it
It's likely that interest-calculating algorithm will grow in complexity in the future and it may need properties that should not be part of Account domain object, like some business constants, list of transactions etc.
Grails (because Spring) naturally supports to have business logic in services (declarative transactions etc.) rather than in the domain objects. You will always have less pain when going along with the framework than otherwise.
I have a repository called LeadRepository that returns a model called Lead which is a person.
The UI I have is a dashboard that displays the following stats. They are all leads but in different states.
Total Leads: 52
Assigned: 49
Unassigned: 3
Contacted: 49
Uncontacted: 0
I am using a stored procedure to query the db. So i'm not using lazy loading to work out the count on the fly.
I have thought about two possible solutions below but neither of them feel quite right.
Use LeadRepository but have a method on it called GetStats() that returns a complex type. This does not have any association with the agg root Lead. Just a bunch of properties that have the different counts.
Create a LeadStatsRepository but this is not really an aggregate root as it has no id. It just is a grouped set of data.
If anyone has any suggestions that would be great.
Repositories are for aggregate roots. What you're after are read models and dedicated query objects.
Stats are best handled through a Service. From Evans’ DDD, a good Service has these characteristics:
The operation relates to a domain concept that is not a natural part of an Entity or Value Object
The interface is defined in terms of other elements in the domain model
The operation is stateless
Stats are a related to a domain object, but not really a part of the entity or value object. They may not be defined in terms of other elements, but it's a possibility. There isn't any state with stats, even keeping them over time isn't truly stateful.
I have a controller and its sole function is to increase a count in a model (i.e. foo_count) and load a view.
Lets assume I have 2 web instances running. If 10 concurrent users were to hit this page/controller at the same time. Will my count be 10?
Will there be a race condition of some sort? Since they are concurrent hits, both web requests will load a copy of model Foobar, with foo_count equals to 0 via FoobarController.
This means they were both operating on their own copy of Foobar that wasn't aware of the change the other web instance was doing. Which also means, the count will unlikely be 10.
What are some ways to resolve this?
You should use built-in records locking to avoid race conditions.
I am reading http://en.wikipedia.org/wiki/Domain-driven_design right now, and I just need 2 quick examples so I understand what 'value objects' and 'services' are in the context of DDD.
Value Objects: An object that describes a characteristic of a thing. Value Objects have no conceptual identity. They are typically read-only objects and may be shared using the Flyweight design pattern.
Services: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.
Value objexts: can someone give me a simple example this please?
Services: so if it isn't an object/entity, nor belong to repository/factories then its a service? I don't understand this.
The archetypical example of a Value Object is Money. It's very conceivable that if you build an international e-commerce application, you will want to encapsulate the concept of 'money' into a class. This will allow you to perform operations on monetary values - not only basic addition, subtraction and so forth, but possibly also currency conversions between USD and, say, Euro.
Such a Money object has no inherent identity - it contains the values you put into it, and when you dispose of it, it's gone. Additionally, two Money objects containing 10 USD are considered identical even if they are separate object instances.
Other examples of Value Objects are measurements such as length, which might contain a value and a unit, such as 9.87 km or 3 feet. Again, besides simply containing the data, such a type will likely offer conversion methods to other measurements and so forth.
Services, on the other hand, are types that performs an important Domain operation, but doesn't really fit well into the other, more 'noun'-based concepts of the Domain. You should strive to have as few Services as possible, but sometimes, a Service is the best way of encapsulating an important Domain Concept.
You can read more about Value Objects, Services and much more in the excellent book Domain-Driven Design, which I can only recommend.
Value Objects: a typical example is an address. Equality is based on the values of the object, hence the name, and not on identity. That means that for instance 2 Person objects have the same address if the values of their Address objects are equal, even if the Address objects are 2 completely different objects in memory or have a different primary key in the database.
Services: offer actions that do not necessarily belong to a specific domain object but do act upon domain objects. As an example, I'm thinking of a service that sends e-mail notifications in an online shop when the price of a product drops below a certain price.
InfoQ has a free book on DDD (a summary of Eric Evan's book): http://www.infoq.com/minibooks/domain-driven-design-quickly
This is a great example of how to identify Value Objects vs Entities. My other post also gives another example.