TopLink design/optimization issues

Question

I've been developing a prototype using TopLink sporadically over the last few months, and I have 2 questions:
1. Is there a way in a ManyToManyMapping to optimize the DELETE SQL statements that are generated when a collection is modified? I have a large number of options that are associated with objects. Whenever I modify these options I get statements such as:
DELETE FROM T_USERSGROUPS WHERE GROUPID = 3 AND USERID= 1
DELETE FROM T_USERSGROUPS WHERE GROUPID = 2 AND USERID= 1
DELETE FROM T_USERSGROUPS WHERE GROUPID = 47 AND USERID= 1
Followed by the INSERT statements.
Is there a way for TopLink to generate 1 DELETE FROM T_USERSGROUPS WHERE USERID=1 and the beginning of this transaction?
2. Many of my frequently used tables contain 50-100 rows of data and the TopLink caching works pretty well. However, I have many instances in my app where I query for ALL of these objects. If I ask for a specific item, the DB is not queried because it is found in cache. However, I would like to avoid a DB query when asking for all objects as well.
I understand the TopLink does provide some optimizations by not actually populating this object if already found, but I'm wondering if there is a trick or setting that would cause TopLink to a[i]Long postings are being truncated to ~1 kB at this time.

Answer 1

2 great questions. For some reason the second question was truncated somewhat though..
1 - Bulk update/delete statements are not supported at this time, but it is on the radar screen and something that is being investigated. The issue is cost/benefit. Engineering needs to weigh the costs of calculating in Java if a bulk update can/should be done vs the speed of just doing the increased SQL calls. Likely, some application intervention would be required.
2 - I can only read the first paragraph, but I think you are asking about in memory queries. The situation you describe is what I would call "reference data", and I would actually recommend not using in memory queries for that -- there is a better way. Simply cache a vector on your own in the app that holds onto all the cached objects. I.e., do a read all query that hits the database first, then cache that collection somewhere. Since it's a finite list, you don't have to worry about size, and since you have a reference to the objects in the collection, the won't be GC'd. This would be faster than doing an in-memory query. Now if you're doing queries to find subsets of the data, it's likely faster to go to the database. Databases are faster at queries than doing the operation[i]Long postings are being truncated to ~1 kB at this time.