Re: EJBs & CMP with real database users

From: Jon Martin Solaas (jonmartin.solaas_at_mail.link.no)
Date: 08/27/04

  • Next message: Jon Martin Solaas: "Re: postgreSQL v. MySQL?" 
    Date: Thu, 26 Aug 2004 22:30:21 GMT

    Fredrik Bertilsson wrote:
    > I am afraid that J2EE will not help you very much here. Normally J2EE
    > applications are using connection pooling. The datasources are defined
    > (url, driver, user, password, etc) in a configuration file. When the
    > application want a connection it makes a lookup using the datasource
    > name. But the database user normally has to be defined in the
    > configuration file.
    >
    > I think that you can't use connection pooling at all. Every user has
    > its own database session. You have to create connections (instead of
    > doing lookup), using JDBC DriverManager. Because you are not using
    > connection pooling, you have to check with you DBA that a user session
    > does not allocate too much memory on the database server. Otherwise
    > your application will scale very bad.
    >
    > I also think that you can't use J2EE transaction handling, because you
    > are not using connection pooling. You have to do commit and rollback
    > explicit in your code. Or you can use some AOP (Aspect Oriented
    > Programming) framwork (like spring framework) and put the transaction
    > code in some post-processing code.
    >
    > Because you are not using the two most important features of J2EE
    > (transaction handling and connection pooling), maybe you should not
    > use J2EE at all. It is a big overhead in money and performance using
    > J2EE.
    >
    > /Fredrik

    How do you propose database-access not using j2ee? Remember jdbc is part
    of j2ee ... Why not use bean managed persistence? It's perfectly
    possible to implement entity beans using any persistence scheme you
    want, including per-user connections to a database. It also makes sense
    to persist the per-user-connection throughout the session in a pool
    instead of re-connecting each time the database needs to be accessed.
    It's certainly better to let all users share all connections in a common
    pool, performance-wise, but it's not mandatory. 

    -- 
jonmartin.solaas¤h0tm4i1
  • Next message: Jon Martin Solaas: "Re: postgreSQL v. MySQL?"

    Relevant Pages

    • Re: Connection pooling in PHP ?
      ... It seems terribly inefficient if every request for data wil incurr the overhead of creating a connection to the db. ... If you move all static data to a separate server and keep only PHP scripts that always use database connections in the same server, setting Apache MaxClients achives the same effect as using a database connection pooling middleware, except that it will be faster as there is no middleware delay the communication with the database. ...
      (comp.lang.php)
    • Torque and Websphere
      ... We are implenting a J2EE project where WebSphere is handling ... connection pooling for the application calls to a database. ... TSTUSER does not own a table called ...
      (comp.lang.java.databases)
    • Wrenching Torque
      ... We are implenting a J2EE project where WebSphere is handling ... connection pooling for the application calls to a database. ... TSTUSER does not own a table called ...
      (comp.lang.java.programmer)
    • Wrenching Torque
      ... We are implenting a J2EE project where WebSphere is handling ... connection pooling for the application calls to a database. ... TSTUSER does not own a table called ...
      (comp.lang.java.softwaretools)
    • Re: Database Auditing and connection strings
      ... We have a need to be able to perform auditing on the database side ... As part of the requirement we must know the userid ... 1) Using a standard ID and password in SQL Server but providing ... This might at least give us an idea as to why connection pooling ...
      (microsoft.public.dotnet.framework.adonet)