Container-managed security doesn't care about most of that stuff. Its primary method of operation is to block requests by unauthorized users to protected URLs so that they never reach application code. It also provides the get userId/getUserPrincipal HTTPServlet request methods, the isUserInRole method, and for EJBs, the ability to protect EJBs both via EJB deployment descriptors and by use of the isCallerInRole() method.
The only thing JSF-specific is that since JSF doesn't always track URLs but the container security system controls using URLs, you have to use the "redirect" JSF navigation option to ensure that people can't use JSF insecure page commandLinks and commandButtons to connect to secured resources.
I'm not an expert in GlassFish, but J2EE servers typically provide plug-in security managers called Realms. When you want to secure a webapp, you set up the basic security rules in web.xml, plus add any security-checking code you need in your application. Then you select a Realm that supports your account security repository (database, LDAP/Active Directory, Single-Signon, or whatever). The application doesn't care which Realm you selected, since they're all plug-replaceable. The details of the Realm itself and its configuration are server-specific, so you'll have to check the GlassFish docs.
In JSF, session are often created long before someone actually accesses a secured URL, but once they do, the login mechanism will kick in and add the security context to the user's session context - and create the session, if no session existed. Doing a session.invalidate() will therefore log the user out in the usual way, although depending on where you go next, a new, insecure session may be created soon thereafter and the cycle will repeat as needed.
Container security doesn't have any knowledge or interest in what database the webapp uses.
As for examples, check any good book on JSPs and
Servlets and
you should find some information on setting up secured transport and container security. You'll typically also find examples of a DIY login in some other part of the book, but like I said, Do-it-Yourself security ... isn't.