Stephan van Hulst wrote:The fact that it works at all is more luck than anything else.
A big part of the problem is that you're passing the same list instance to every asynchronous task handler and clearing it instead of creating a new one. So not only does every handler work with the same list of lines, the lines are cleared at the same time that the processing begins.
Piet Souris wrote:hi Stanley,
as said: it is not a question of whether a Function works and a Consumer doesn't, but the question what is a legal Function and what is a legal Consumer.
I must say: your code, although nothing wrong with it, is not very transparant. To make the error a little easier to spot, let's make a separate Function and a separate Consumer. If you get an error in one of these, then you know that the problem is not in the 's.changeState(2)' part of the code,
So here goes:
So, when we apply this function to some StateCount c, then the return value is c.count + 1.
On its own, c.count + 1 means nothing, you get a compiler error here, stating that this value should be assigned to a variable. Now have a look at the method 'stateChanged':
You invoke it with:
So, in effect, what you do is saying:
and as you can see, this is perfectly legal code.
Now for the Consumer part. Again, let's check if the Consumer as you defined it is correct:
As you will notice, this gives a compiler error, stating that an int (the result of the right part) cannot be converted to void, as a Consumer must be.
So, let's try a variant:
Now we return nothing, but as before, we get the error that the right hand part is not a statement and should be assigned to a variable.
Well, let's do that, but the way I do it makes it necessary to make the variable 'count' available to other classes as well: make it a public variable (that is bad practice, never do that in your code, but it is just for demonstrations sake)
And that is perfectly legal as well.
So, with the Function sToi and Consumer consumer defined (and legal), we can invoke them, either as you invoke them,but also as follows:
As said, having the separate sToi and consumer makes it just a tad easier to see what is going on.
Looking back, I must admit that this is actually not an easy subject at all! It is a subject that takes a lot of practising, and a lot of trying until you get it right! But the reward of putting all that effort is there: it is big fun working with all of these Consumers, Functions, Predicates and similar. Of course, if you have additional questions, just come up with them.
Junilu Lacar wrote:Additionally, your usage of the Function and Consumer interfaces are smelly. I can't quite put my finger on it but it just seems like there's way too much unnecessary intimacy between the StateCount class and the lambdas. The lambdas having a reference to StateCount does not look right to me. And Consumer seems like the opposite of what you should use. That is, it seems to me a
ProducerSupplier is more appropriate for what you want to do. I'll try to come up with an example to show something I think is more sensible.
Junilu Lacar wrote:between the StateCount class and the lambdas
Piet Souris wrote:hi Stanley,
it is the expresson 'c -> s.getCount() += 1' that is invalid. In fact, it boils down to: s.getCount() = s.getCount() + 1, which is invalid.
If you add the method
and make the Consumer:
then all is well.
MockedFetchFromTable.parallelFetchFromTwoTable() second result----->nameId#first name#secondName
It is not intended that implementors be threadsafe. Instead each thread/transaction should obtain its own instance from a SessionFactory.
Obtains the current session. The definition of what exactly "current" means controlled by the CurrentSessionContext impl configured for use.