|
|
|
Well, what does everybody think about this extension?
We already used this successfully in our application.
Martin, I think your patch is quite clear and precise. I wonder, though,
whether we should actually overload Databaseload() to provide this functionality, and not add a property to Database(Impl) ? Just a question: I think that somewhere in the PAI, Castor JDO allows you to
elevate a lock from 'read' to something higher, e.g. 'write'. How would this interfer with your ideas ? Btw, if you wondered about what PAI stands for, don't worry ..
![]() say 'API', of course. I'm of two minds on this.
Either: Read only objects are critical to keep, in which case the hashtable is a correct implementation Or: Keeping these things around forever is pointless, and moving to a weak reference is the right The weak hash ref is probably the easiest transparent change to make, and will likely behave correctly A flag, instead of setting whether or not read only objects should be remembered, could then allow you Implementing a switch that allows you to select the referent style - strong, weak, soft, or phantom - Drawback: it requires you to create reference objects, which increases the number of objects we have What's a good article on weak/phantom references ? It looks like I need to
educate myself a bit .. ![]() The requested feature only relates to access mode ReadOnly and can not be used
with other access modes. As suggested by Martin someone that wants to use the new feature would have to call setRememberReadOnlyObjects() and call load() or execute() with access mode ReadOnly. A drawback of the suggested solution is that it will not be possible to load objects with access mode ReadOnly that are remembert in the transaction with others that should not been remembert. I suggest to introduce a new access mode ReadOffTransaction to implement the In addition we need to think about what will happen if the requested object is I don't think we can use soft-, weak- or phantom-references in The javadoc is not to bad but I can also search for some articles in magazines
if you like. Don't worry, Ralf. Unless a particular article springs to your mind immediately,
I'll be happy to browse myself. > In addition we need to think about what will happen if the requested
> object is already part of the transaction. I think it have to remain > in the transaction and the load() or execute() with access mode > ReadOffTransaction behaves as with access mode ReadOnly for this object > only. Without commenting upon the feasability of this suggested approach, this looks to me like we need to add even more if-else-ifs to an already quite convoluted code base. Java in a Nutshell is my bible on references behavior.
As for long-term stuff; Basically, it's read-only. I'm only talking about modifying the read-only portion However, it's probably safe to use references for anything in the read-only section. > ... and it's under the assumption that anything in the read-only section
> can safely go away. As mentioned above, a read lock for an object can be upgraded. If we 'did away' with that object, this could be a problmem. > I suggest to introduce a new access mode ReadOffTransaction to implement the
> requested feature. This would not have the disadvantages from above. Would be fine with me. But could you please explain what the > In addition we need to think about what will happen if the requested object is Perhaps someone can explain me why the accessMode is translated into an >Would be fine with me. But could you please explain what the
>name "ReadOffTransaction" stands for? I could think about a new constant with a >name like "PlainRead" or "BatchRead" in the Database interface. I used 'ReadOffTransaction' as it is a read only without adding the objects read >Perhaps someone can explain me why the accessMode is translated into an Well, I though of keeping the Database interface as it's now (just adding a new
constant for the read-only-dont-remember mode) and dropping the AccessMode class. If you search where the AccessMode class is used you may recognize that it will
be rather complicated to remove it (211 references). In addition I prefer enumerations like AccessMode over unrelated short primitives. I'll prepare a patch about my ideas to modify AccessMode and clean up Database Created an attachment (id=989)
Patch to make usage of AccessMode public |
proposed patch