All entries for Wednesday 29 August 2007
August 29, 2007
Another thing that would make my life easier; Sun have a fantastic java GUI console redirection tool that you can use with their iLOM to get the system graphical console output. But it works by communicating over a variety of ports that our firewall doesn’t allow, so I can’t use it from home.
Surely there should be an option somewhere to tunnel it all over ssh instead? There must be an easier solution than VNC-ing (over ssh) onto my desktop at work and running the rconsole from there?
(Yes, I could ssh straight in to the ilom and get the text-only console. But it seems a shame to let the lovely graphical version go to waste…)
Hibernate is lovely, but I wish that it would provide me a thread-safe Session implementation. We’ve got a couple of servers which are more or less as fast as you can buy, in terms of single-threaded performance, and a few points in our app which could be faster. Now, these servers have 8 cores each, and typically only have one or two threads in the run queue at any given time; i.e. 6 of the cores are basically idle. So it would make a lot of sense if we could take a request, split it into 4 components, and distribute those components over 4 separate threads. If we could do that without too much overhead, we could actually switch from our relatively power-greedy opteron chips, to something a bit more frugal like a Sun T1, which would be nice.
However, our apps are processing hibernate persistent objects, which means that they need a session to operate within, which means they are bound to a single thread.
We could create 4 threads and give each one a new session, but that means that each thread will need to re-query for it’s data, since the hibernate L1 cache is bound to the session. So that won’t work. We could deploy a level 2 cache, but they we have to somehow manage to invalidate all the data that a particular request has loaded without affecting other, concurrent requests (we have no shared cache between requests, so that (a) we don’t need much heap, and (b) we can loadbalance between multiple machines and JVMs without needing to share the cache.
So we’re stuck in an awkward position. We can’t multithread the app any further, because all the performance we’d gain by spreading processing over more cores, we’d loose by having to re-read the same data over and again from the DB.
What I really want, I guess, is a Level 1.5 cache – something that’s bound to the operation rather than the session, and that can be shared between multiple threads which are co-operating to do all of the processing that’s needed. Alas, it seems such a thing doesn’t exist.
Update It would seem I’m not alone. “Uncle” Bob Martin blogs about exactly the same problem, albeit at a slightly higher level of abstraction.