On 13/01/2004 15:44, "Thomas Mahler" <[EMAIL PROTECTED]> wrote:
> Hi Pedro,
>
> Pedro Salgado wrote:
> <snip>
>>>
>>> Sure, this is much cleaner. But my code is only one line ;-)
>>
>>
>> Yes, but if I make an additional util class I can get the same effect (1
>> line) and abstract from the JDO implementation ;)... Maybe one more private
>> attribute for the pmf on usecase implementation classes...
>
> you are right. Of course it makes sense to hide the actual JDO
> implementation from the user code.
>
>
>>
>>>> Another question...
>>>>
>>>> What are the limitations of this JDO plugin? Can I use it safely for
>>>> makePersistent, deletePersistent and getObjectById and transaction
>>>> management (these are the only methods I need)?
>>>>
>>>
>>> I don't know of any restriction wrt. the JDO programming model.
>>> The only thing that is problematic is the query mechanism:
>>> if a JDOQL query is processed, the JDORI load the complete extent (i.e.
>>> all instance of a class) and matches each object against the search
>>> criteria. This can be a performance killer for large tables.
>>
>>
>> What if I use directly the JDBC connection using PersistenceBroker? Can't
>> I have the best of both worlds?
>
> sure you can. But of course your app is than no longer purely JDO
> compliant...
>
>> I don't want object cache... At least for now... So I am currently using a
>> mixed solution between OJB Persistence Broker and JDBC. This way I
>> make/delete/getByPK persistent objects very easily (and have a simpler yet
>> effective model) and have the performance I need with JDBC (I guess this
>> implies that I can't have object cache).
>
> depends on what you do exactly...
>
>> I started abstracting OJB so I could switch to JDO in the future but, I
>> realized I was developing something that already existed :D... So now I am
>> planning to move to OJB JDO plugin but I am having second thoughts whether I
>> can use the same JDBC retrieval strategy (for PersistenceBroker it worked
>> very well).
>>
>
> sure, that's possible.
> With my statements I was referring to the *internals* of SUN's JDO RI.
> it provides a plugin mechanism that abstracts the backen storage. An the
> OjbStore is an incarnation of such a plugin.
> So when I coded the OjbStore Plugin I had no options to do any kind of
> jdbc by passing or something. Simply because the RI never aks the Plugin
> to perform any kind of query, but simply asks: give me all instances.
>
> The only solution would be to change parts of SUN's JDO RI which is not
> possible to us as it is closed source.
>
> But you are talking about *external* user code. Of course you can do any
> kind of mixture of OJB Apis. You can use JDO, PB, ODMG and OTM in
> paralell and spice it with some JDBC calls. no problem!
ok.
> You just have to take care with transaction boundaries.
Even if I use JDBC calls just for more complex selects (just to present
data to the user) and insert, deletes, updates and selects by primary key
through JDO?
Do I really need to begin and end a transaction even if I am just getting
data from the database to present it to the user?
I am checking the OJB-JDO plugin and it seems that the plugin uses pbroker
to get a transaction -> they share the same transaction management system?
Or are you saying that OJB(in general)/JDBC may cause non-transaction-safe
operation?
Would this solve the transaction problems?
try {
broker.beginTransaction();
Result result = null;
Connection conn = broker.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(query);
result = ResultSupport.toResult(rs);
rs.close();
broker.commitTransaction();
} catch (Exception e) {
log.error(query);
log.error(e);
broker.abortTransaction();
}
return result;
Thanks for your responses. They have been a great help.
Pedro Salgado
>
> cu,
> thomas
>
>>
>>
>>> unfortunately the JDORI plugin mechanims does not provide any interface
>>> to delegate queries down to the persistence kernel. SO OJB can't do any
>>> optimizations here and must load all instances of the extent and reach
>>> them back to the JDORI layers. This is one of the main reasons why we
>>> want to write our own JDO implementation.
>>>
>>> The good news in your case: getObjectById() is not affected by this
>>> problem and works very efficiently.
>>
>>
>> That is certainly good.
>>
>> Thank you for your response,
>>
>> Pedro Salgado
>>
>>
>>> cheers,
>>> thomas
>>>
>>>
>>>
>>>
>>>> Thank you,
>>>>
>>>> Pedro Salgado
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
