Topic
  • 1 reply
  • Latest Post - ‏2008-12-14T11:39:02Z by bluebird
SystemAdmin
SystemAdmin
8614 Posts

Pinned topic Use of ServerJDBCHelperAccessBean

‏2008-12-05T18:51:58Z |
Hello All,

I want to find out if the WCS community out there has used ServerJDBCHelperAccessBean() calls in their code. Is it a preferred method to employ this class to make some quick data retrievals from the DB? Specifically, I am looking for answers if this is a widely used method to fetch data from the database, or if there's an alternate method used. Moreover, what is IBM's stand on the next releases of this class? Would anyone know if this class will be deprecated in the future? Does IBM recomend the use of this class to begin with?

Some questions I could use answers on are:

  • Are there any special considerations around use of ServerJDBC...when it comes to making DB updates?

  • What about the use of the flush() method?

  • What situations or exceptions does one commonly run into?

We use it extensively in our implementation and have run into no problems. But my team wants to be aware of any downstream impact on the use of this with newer releases. Will code migration become an issue?

Thoughts and experienes of users who have used this command are greatly appreciated.

Thanks,

-Sudarshan
Updated on 2008-12-14T11:39:02Z at 2008-12-14T11:39:02Z by bluebird
  • bluebird
    bluebird
    271 Posts

    Re: Use of ServerJDBCHelperAccessBean

    ‏2008-12-14T11:39:02Z  
    Sudarshan,

    The ServerJDBCHelper is widely used for fetching data outside of the CMP EJBs, especially to improve performance when data is retrieved from multiple tables. As you note, it can also be used for making updates.

    When you make updates you need to be aware of possible conflicts with the EJB container, especially if you try to update the same data via the ServerJDBCHelper and regular CMP EJBs. This is partly the reason for the flush method, which allows you to tell the EJB container to flush all DB updates that it has cached so far.

    Another point to be aware of is the OPTCOUNTER column, which you are responsible for updating yourself if you choose to execute direct SQL updates against the database.

    For these reasons, I would not recommend using the ServerJDBCHelper to update the database yourself.

    I prefer not to use the ServerJDBCHelper in the code, as it spreads out the SQL across the code base. I prefer concentrating database updates in custom session beans, who would typically extend one of the various XxxJDBCHelper classes. This way you can group common logic and the DBA can get a better view of the SQL the code may exercise database with.

    The ServerJDBCHelper is not deprecated and I cannot say whether it will be, but the future direction is definitely to use the Data Services Layer (DSL), as it offers better abstraction from the specifics of the database implementation.
    So to summarise: Yes, you can use the ServerJDBCHelper for queries and updates. I would not do the latter and implement the former in custom session beans. For future implementations, you should consider the DSL.
    Regards,
    Nicolai Dufva Nielsen