openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: CMP2 on G2 - Delayed Database Flush
Date Mon, 14 Apr 2008 22:46:16 GMT
One other thing occurred to me... while you are looking at the  
flushing code, you should double check that I implemented optional  
flush-before-query stuff.  I'm not sure if I got around to doing that,  
and it can have a serious performance impact to not allow users to  
disable flushing before queries are executed.


On Apr 14, 2008, at 1:04 PM, Dain Sundstrom wrote:
> On Apr 14, 2008, at 6:08 AM, Rick McGuire wrote:
>> I've not come up with any clever way of implementing the cache so  
>> far, other than just keeping a list of objects whose primary keys  
>> have not been calculated, and then, if all other lookups fail,  
>> start resolving the primary keys looking for the given target.  Not  
>> elegant, but I think this will work.
>> I do wonder if another approach might work better.  If I understand  
>> the reasoning behind the flush, it is necessary because it's  
>> possible that some of the information needed to calculate the  
>> primary key only becomes available after the JPA flush()/merge()  
>> sequence.  I suspect for many objects, this is not needed because a  
>> simple primary key is used.  Would it be feasible to detect the  
>> situation where a flush is needed to "crystalize" the object to  
>> calculate the primary key?  This way, simple object instances where  
>> the primary key is provided in the create() operation would not  
>> experience the performance hit.
> Hummm... this is becoming a much more interesting problem.
> In the cmp system, the JPA persistence.xml is the master source of  
> mapping information.  In CmpJpaConversion we convert the CMP  
> declarations in the ejb-jar.xml file to a persistence.xml (JaxB  
> objects), but a user can provide the persistence.xml file directly  
> effectively bypassing this code.  It should be easy to add a step to  
> CmpJpaConverstion (or a new DynamicDeployer) that walks the  
> persistence.xml JaxB objects and notes which beans have generated  
> primary key fields.
> Hopefully knowing which CMP beans use generated primary keys will  
> make the cache work easier, since you will know that a user can't  
> possibly ask for an object by primary key when you haven't resolved  
> the primary key for the user yet.
> -dain

View raw message