Actually, the first sentence "In public key cryptography we can also use session keys which are symmetric." is a bit misleading, if followed by the second sentence. The public key part is there just to make sure that the session key gets securely to its receiver.
In general, for a one-directed information transfer from Bob to Alice, Bob can use Alice's public key to encrypt something, and Alice will use her private key to decrypt the same information. In hybrid schemes, this something is usually a symmetric session key, which will be used for encryption (and integrity check) of the main message. If the encryption scheme is secure (and Alice's private key stays private, and Bob really has her public key), Eve (the attacker) has no chance to read (or modify) the data.
This is used for emails (e.g. PGP and S/MIME), data storage (where Bob = Alice), and other off-line communication.
For a broadcasting scheme, the session key would have to be encrypted with all the intended receivers' public keys (in parallel), so each of them can decrypt the session key using its own private key, and then use the session key to decrypt the data.
Encrypting something using the senders (private or public) key is not useful in any way.
For one-line communication, we usually want to secure not only data transfer in one direction, but bi-directional communication. At the same time, often one of both sides (often the "client") wants to stay anonymous, while at least one side has to be authenticated in some way. Here the common "public-key encryption" way is that Bob creates some random data, encrypts it by Alice's public key, and sends it to her. Alice decrypts it, and both derive some common secret keys from this random data. Alice can then encrypt data to Bob with this session key, without even knowing who Bob is.
This is the core of RSA key exchange as used in SSL, and as Will answered, as soon as someone gets Alice's private key, all the previous interactions can be decrypted.
To avoid this problem and achieve perfect forward security, one can use something like the Diffie-Hellman key exchange (or its elliptic-curve version). In this, both Alice and Bob send generate some (short-lived) private key, generate a public key from this (which is exchanged unencrypted), and combine the received public key with their own private key to get the session key – miraculously, they both will derive the same secret, and an attacker will not be able to do so. (The private keys can be destroyed after deriving the shared secret.)
To make sure that Eve is only listening and not doing an active attack, there still needs to be some way to make sure the messages are not modified (a man-in-the-middle attack). For this, usually Alice will (using her private key) sign a hash of all messages part of the exchange, and send this to Bob, so Bob can verify with her public key that he is really talking with Alice, and not to Eve pretending to be Alice. (Thus here we need an asymmetric signature scheme, too: RSA, DSA and ECDSA are popular choices here.)
(Alice doesn't really care with who she communicates, as long as it is the same entity throughout the connection, which is ensured by the MAC used for all messages. If Alice also needs Bob to be authenticated, this can be done afterwards, for example with a password, or a client certificate.)
This is also a popular mode of using SSL (as it is secure against long-term attackers), and the only mode in the SSH 2 protocol.
