New to Hibernate here.

In a Swing/WebLogic application, must the Swing application make database connections directly to the database in order to leverage the advantages of Hibernate?

If so, which database account is typically used? A database account shared amongst all users that has read/write access? Or separate database accounts for each user (thus necessitating a lot of sysadmin overhead)?

If a common DB account with read/write access is used, how is that password secured if it's sitting in a JAR downloaded to the user's client PC? I suppose an improvement to that would be to have an EJB supply the password to the client, but it would still be in the client RAM.

And even if that is done in conjunction with separate user accounts, a user could snoop the password in PC RAM and then use it for unlimited read/write access. The only advantage over a shared account is that the access would be logged and tied to that user.

the app talks to hibernate and hibernate talks to the database. you code as though there were no database. your 2nd question depend entirely on what the biz requirements are. and, yes, if your requirements say that a machine must make a connection to the db, then the password is going have to be somewhere on that machine if it is not going to be supplied by a user .

Under what circumstance would a Swing client using Hibernate not make a connection to the database? I.e., is there an alternative?

I guess what I'm thinking is that in the ideal world, an ORM tool would have a client piece and an application server piece, where the communication between the client and the application server is done with the user's login to the application, and the communication between the application server and the database is done with an application/system ID that has read/write access. That way, the database password is never on the client machine and the only possible database accesses are those that are locked up in application code residing on a secured application server.

But from my limited knowledge of Hibernate, it does not seem to work this way -- Hibernate sits either on the client or the application server but not both.

In short, is Hibernate bringing back some of the disadvantages of client/server (compared to 3-tier) in exchange for the advantages of object-oriented persistence?

there is no alternative. maybe you need a web service or something.

Your term Swing/Weblogic is a little confusing. Do you have a two layer application:

a.) Swing app <--> Database

or a three layer application:

b.) Swing app <--> Weblogic Server <--> Database

or some non-orthogical application where the Swing app talk to both the weblogic server and the database?

If your application is a three layered application, your weblogic server should manage all database connections and your should use the disconnected object features of Hibernate to allow you to pass objects and their changed version back and forth between the server and the swing app.

If your application is a two layered application, what are you using weblogic for? Regardless, you may want to promt for a userid/password in the swing application and have multiple users in the database that have the same roles set up.