LMB will work in this scenario, although I wouldn't push the data itself, probably just a 'refresh now' indicator that portlet B uses as the signal to pull the data again.
Note that you may have issues in a cluster, I'm not sure if the LMB crosses the cluster nodes by default (or even if it is possible).
I use LMB in conjunction w/ a spring-based JMS listener - message comes in, jms listener code gets invoked. From there I use LMB to route message to different logged in users to distribute notifications.
Works like a charm, but there were some initial hurdles that I had to overcome that you'll need to keep in mind... LMB really is more at a systems level than a user level - this portlet sends a message to a system component that does something with it, but not very dynamic for cases when users log in/log out to create/dispose of the destinations. I had to build up a set of classes to create and destroy destinations on the fly, query for destinations, etc.
The common example is how Liferay sends an email to subscribed users of thread. When a new message is posted to the thread LMB message goes out to a always-there component which handles the sending of the email. Not really user based, much more of a static sort of system.
When you're trying to send to a specific user, then you're tracking when the user logs in (to create the destination) and when they log out (to destroy the destination), and the sender needs to be able to get an updated list of available destinations (hint: naming your destinations here will be crucial) in order to find one (or more) to send the message to...
Log out is tricky, I'd recommend using a logout action just to ensure you get some level of cleanup, along with an http session listener so you can clean up even if the user didn't actually log out (but timed out instead)...
Fun, fun, fun...
