jdb has a 'monitor' command which allows you to specify a jdb commmand to be executed each time the debuggee stops, eg, at a breakpoint.

When the stop occurs, jdb shows the user the prompt, eg
   main[1]

and then executes the command specified in the monitor command.
However, jdb gives no indication that this command is being executed - ie, the user cannot tell if the thread actually is stopped and jdb is ready to accept a new command or not.
Here is an entry from my nightly analysis report:

New nsk.jdb failures (from 2008.09.25)
    nsk/jdb/monitor/monitor001
        This test failed due to "nsk.share.Failure: Debuggee did not
        exit after 1 <cont> commands" on Linux IA32 Client VM (machine
        jtg-linux17).

        The jdb.session log shows some strange overlapping:

        line 01 main[1] ** fields list **
        line 02 nsk.jdb.monitor.monitor001.monitor001a _monitor001a
        line 03 main[1] main[1] monitor
        line 04 1: threads
        line 05 2: methods nsk.jdb.monitor.monitor001.monitor001a
        line 06 3: fields nsk.jdb.monitor.monitor001.monitor001a
        line 07 4: eval (new java.lang.String("Hello, World")).length()
        line 08 main[1] cont
        line 09 > Thread not suspended
        line 10 (new java.lang.String("Hello, World")).length() = null
        line 11 Current thread isn't suspended.
        line 12 main[1] quit

        Lines 01 and 02 show the fields monitor prompt and output.
        Line 03 shows the eval monitor prompt but no output and it
        shows another prompt and the "monitor" command; the eval
        monitor output isn't until line 10 which is after the "cont"
        command. jdb's response to the "cont" command is "Thread not
        suspended" followed by the eval monitor output. There is also
        "Current thread isn't suspended." on line 11.

        I'm wondering if jdb can do some things in parallel, e.g., the
        "monitor" command at the same time as the eval monitor is being
        processed. However, "cont" is one of those commands that needs
        the target VM to be in a particular state so trying to do a
        "cont" when something else is executing isn't going to work.