Discussions

EJB design: DOA pattern with Rowset Wrapper List strategy

  1. DOA pattern with Rowset Wrapper List strategy (3 messages)

    This question is a bit more on the academic side. I am developing educational materials for internal training in J2EE patterns. My question is about use of the Data Access Object Pattern, RowSet Wrapper List strategy. In Core J2EE Patterns (Alur et al) this strategy is described as being useful for finder methods returning large resultsets, and the example uses a Read Only RowSet internally. Is there any reason this strategy should be limited to read only situations? Are there likely pitfalls in using this strategy with an updateable application? Put another way, is there a better strategy for working with large result sets and updates? Any insight would be appreciated. Thanks! -Tim
  2. The rowset wrapper is for typically situations, where you need to be able to close the connection and still have access to data (vs resultset where you cannot access the data once you close the connection, or the corresponding statement object in case of pooled connection). Hence its best suited for readonly data, where you execute the query, get the data, close the connection and keep the rowset for a while to access the data returned by your query. For situations where you need the option of updating, you need to typically implement some kind of locking strategy (best strategy being optimistic locking). So if you use a rowset, you might want to perform an update separately checking if the data has been changed since the last read, and take an appropriate action. Alternatively using a ResultSet will allow you to hold the connection and update later. Hope this helps. Regards, Rakseh.
  3. Thanks Rakesh! -Tim
  4. I have a related question now, regarding the Read Only RowSet strategy of the DAO pattern. "Core J2EE Patterns" (Alur, Crupi & Malks) describes this strategy: developing a custom Read Only Rowset that under the hood makes use of a disconnected, cached RowSet. The book does not describe the value of this pattern, which is what I'm curious about. Is it: - Less development because the custom class does not need to handle updates? - Security (If others make use of the class in their development, you can be reasonably sure they won't be making updates)? - Better performance? (This seems improbable since it still uses a cached RowSet object internally) - Something I haven't considered? - A combination of some of the above? I'm developing internal training for my company and I want to ensure that uses of the strategy are described appropriately. Thanks! -Tim