Home Workout

Posted on Updated on

On Tuesday evening I decided to do a bit of a home workout and practice some moves that I’ve not performed for a while.  My right deltoid still isn’t happy, so I’ve had to take it easy.  Here’s what I did:

Reps: 21 – 15 – 9

  • 12kg dumbbell curls
  • 16kg kettlebell squat
  •  Sit-ups

Note that the dumbbell curls were done 1 arm at a time due to insufficient weights, so 21 – 15 – 9 reps per arm.  Unfortunately I forgot to time myself.  I’ll repeat this over the next few days and publish my time.

Advertisements

Late Summer Cycling

Posted on Updated on

I went out for a ride today for the first time in a while.  I took the train from London Paddington to Newbury where the ride started.  I ended up going a lot further than I’d planned and some serious saddle soreness aside, it was a great ride in great weather.

I’ve discovered that I need a way of carrying much more water than I normally do.  I need far more than 750ml of water for a 37 mile ride.  Maybe I need a Camelback, at the very least I need a second bottle cage and bottle to give me 1.5 litres.

Injury

Posted on

I somehow managed to injure my right shoulder, either the deltoid or subscapularis whilst doing toes to bar for time.  Pull ups aren’t helpful for recovery so I’m having to lay off upper body work for 6-7 days.  I made the mistake of doing a set of kettlebell swings last week – not clever.

CrossFit WOD

Posted on Updated on

CrossFit tonight was a tough one. Maybe because I’ve been away for a few weeks. Here’s how I did:

  • Push jerk 3-3-3-3-3.  20kg olympic bar and 20kg plates (40kg total)
  • Pull ups 5x max reps.  4 strict in most sets, using black band.

The WOD was 21-15-9 of the following:

  • Push press (20kg bar, 10kg plates)
  • front squat (20kg bar, 10kg plates)
  • Sit ups

The pre-WOD exercises were challenging, but I was probably very close to the limit of what I could lift.  The WOD was difficult, I should probably have gone with 5kg of plates instead.  Note for next time.

Blitz8 Reborn

Posted on Updated on

The previous version of Blitz8 was hosted by Apple as part of my subscription to MobileMe. When MobileMe was discontinued I had a look around to see what the best option was to keep this site alive.

I’ve used WordPress a lot before. I never really liked the hassle of paying for/setting up a database and then managing WP upgrades – I just don’t have time for that anymore. For just a few dollars a year I’ve been able to continue with WordPress, but as hosted solution. They take care of setup, upgrades etc, I just post.

Some of my old content still lives on, here.

Processing with WebLogic Singleton Services

Posted on Updated on

I’ve recently had cause to come up with a means of running some code on precisely one managed server in a WebLogic cluster at once, and ensure that the functionality is highly available – i.e. it will migrate to a secondary server if the primary fails.  Take the following scenario, for example:

You have a number of managed servers in a WebLogic cluster, and you’re using a market data service such as Reuters RDMS or Bloomberg’s Market Data system.  You want each item of data to be processed exactly once, and you don’t want to (or can’t) make use of JMS as a means of message ordering and distribution.

Fortunately, WebLogic provides an interface that allows you to define a service that will be present on only one server in a cluster at once – the Singleton Service.  Java classes that implement the Singleton Service interface can be plugged into WebLogic’s Service Migration Framework and can therefore benefit from the powerful functionality that the framework offers.

To prepare for the deployment of a singleton service, you need to configure a leasing strategy.  Leasing is the process WebLogic Server uses to manage services that are required to run on only one member of a cluster at a time. Leasing ensures exclusive ownership of a cluster-wide entity. Within a cluster, there is a single owner of a lease. Additionally, leases can failover in case of server or cluster failure.

To configure leasing, you change the “Migration Basis” value in Cluster -> Migration.  You’ve got two choices:  consensus leasing or database leasing.  Setting Migration Basis to Consensus leasing means that the member servers maintain leasing information in-memory, which removes the requirement of having a high-availability database to use leasing.  This does mean that you need to have a node manager running on each managed server node in the cluster.  Once you’ve set this up, you’re ready to write some code.

In its simplest form, a WebLogic Singleton Service looks like this:

package com.blitz8.examples;

import weblogic.cluster.singleton.SingletonService;

public class ProcessorSingletonService implements SingletonService {
  private static final String CLASSNAME = ProcessorSingletonService.class.getName();

  public TradeProcessingSingletonService() {
  }

  public void activate() {
    System.out.println("activate() called for " + CLASSNAME);
  }

  public void deactivate() {
    System.out.println("deactivate() called for " + CLASSNAME);
  }

}

Once compiled this class can be packaged into a deployable artifact (for e.g. an EAR file), and deployed into a WebLogic domain.  Before this service will work, you need to tell WebLogic about it in order to allow WebLogic to register your service with the Service Migration Framework.  This is done by including the following XML stanza in your weblogic-application.xml deployment descriptor:

<singleton-service>
  <class-name>com.blitz8.examples.ProcessorSingletonService</class-name>
  <name>ProcessorSingletonService</name>
</singleton-service>

The schema for the deployment descriptor tells us that this needs to be a direct child of the <weblogic-application> node.

Deploy the artifact containing the weblogic-application.xml deployment descriptor and compiled Singleton Service into your domain.  Look at the server log files for evidence that WebLogic now knows about your Singleton Service, and look out for a message around the time the server switches into RUNNING mode telling you which managed server has been selected to host your Singleton Service.

You should now be able to replace the System.out.println(...) statements with your own business logic code, having proved and understood the concept of a Singleton Service.

To bind or not to bind… Using bind variables when working with Oracle

Posted on Updated on

I’ve been working with Oracle for a little while now, and wanted to understand the kind of difference that using bind variables made. I did some thinking around how I could perform an experiment, and came to the conclusion that the purest approach would be to write two simple stored procedures, one that makes use of bind variables and one that doesn’t, run them both and measure response time.

First I needed a table to use with my procedures, so I created one on my schema:

create table t ("y" number(10,0))

Procedure 1 – with bind

create or replace
procedure test_proc_bind
as
start_ts timestamp;
end_ts timestamp;
diff_mins number := 0;
diff_secs number := 0;
begin

-- Capture start time
select systimestamp
into start_ts from dual;

-- Loop and insert
for i in 1 .. 100000
loop
execute immediate
'insert into t values ( :x )' using i;
end loop;

-- Capture end timestamp
select systimestamp
into end_ts from dual;

-- Calculate the difference in minutes
select sum(
extract(minute from end_ts) - extract(minute from start_ts)
) into diff_mins from dual;

-- Calculate the difference in seconds
select abs(
sum(
(extract(second from end_ts) - extract(second from start_ts)))
) into diff_secs from dual;

-- Print stats
dbms_output.put_line('Started at ' || start_ts);
dbms_output.put_line('Finished at ' || end_ts);
dbms_output.put_line('Test took ' || diff_mins || ' minutes, '
|| diff_secs || ' seconds');

-- Clean up
delete from t;

end;

Procedure 2 – without bind


create or replace
procedure test_proc_nobind
as
start_ts timestamp;
end_ts timestamp;
diff_mins number := 0;
diff_secs number := 0;
begin 


-- Capture start time
select systimestamp
into start_ts from dual;


-- Loop and insert
for i in 1 .. 100000
loop
execute immediate
'insert into t values ('||i||')';
end loop;

-- Capture end timestamp
select systimestamp
into end_ts from dual;

-- Calculate the difference in minutes
select sum(
extract(minute from end_ts) - extract(minute from start_ts)
) into diff_mins from dual;

-- Calculate the difference in seconds
select abs(
sum(
(extract(second from end_ts) - extract(second from start_ts)))
) into diff_secs from dual;

-- Print stats
dbms_output.put_line('Started at ' || start_ts);
dbms_output.put_line('Finished at ' || end_ts);
dbms_output.put_line('Test took ' || diff_mins || ' minutes, '
|| diff_secs || ' seconds');

-- Clean up
delete from t;

end;

OK, so we have our test table and two procedures. You can see that the both procedures INSERT 100,000 values into the table T, then do some stats processing. The next step is to run the two procedures and see what happens to the response time.

matt@XE> exec test_proc_bind
Started at 19-SEP-08 08.44.23.046327 PM
Finished at 19-SEP-08 08.44.27.550171 PM
Test took 0 minutes, 4.503844 seconds

PL/SQL procedure successfully completed.

matt@XE> exec test_proc_nobind
Started at 19-SEP-08 08.44.35.772012 PM
Finished at 19-SEP-08 08.47.00.069557 PM
Test took 3 minutes, 35.702455 seconds

PL/SQL procedure successfully completed.

matt@XE>

The results were as I expected, the procedure that used bind variables took substantially less time than it’s non-bind variable using counterpart. Clearly there is a lesson here…