jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-63) /contrib/orm-persistence/ OJBPersistenceManager
Date Thu, 17 Mar 2005 18:15:21 GMT
     [ http://issues.apache.org/jira/browse/JCR-63?page=comments#action_61134 ]
     
Edgar Poce commented on JCR-63:
-------------------------------

I'm not an expert in OJB but I use it pretty much. AFAIK The persistence broker wraps a single
connection and performs any action through it. 

Regarding transactions in multi-threaded environments, if a single broker is used it might
lead to unpredictable behaviour.

The broker must be obtained and released in the single method that handles the entire trasaction,
store(ChangeLog log) in this case. And the broker instance should be passed to any private
method that adds an action in the transaction, e.g. store(NodeState). I think that would be
thread-safe beacuse a new broker would be obtained from the pool on each request.

The same applies to hibernate, it's not an OJB specific issue.

> /contrib/orm-persistence/ OJBPersistenceManager
> -----------------------------------------------
>
>          Key: JCR-63
>          URL: http://issues.apache.org/jira/browse/JCR-63
>      Project: Jackrabbit
>         Type: Bug
>     Reporter: Edgar Poce
>  Attachments: orm-ojb.patch
>
> OJBPersistenceManager seems to have the following problems
> 1. OJBPersistenceBroker inherites from AbstractPersistenceBroker. There's no 
> need of using a non transactional implementation as the feature is available in 
> jdbc. 
> 2. A single broker is used and It's not thread-safe. This is not a problem now 
> because it inherits from AbstractPersistenceManager, and the store(ChangeLog ) 
> method is synchronized.
> 3. The broker is never closed so it leaves an open connection.
> 4. There's no pooling with only one broker.
> 5 Each write method (e.g. store(NodeState state)) starts its own transaction 
> but the transaction should start and end in store(ChangeLog log).
> 6. It never rollbacks, even when an item in the changelog can't be persisted.
> 7. The mysql example create MyISAM tables which don't support transactions. 
> Innodb tables would be more appropriate.
> 8. jdbc to java type mapping is wrong for 
> class: org.apache.jackrabbit.core.state.orm.ORMBlobValue
> field: size
> Changed from INTEGER to BIGINT
> 9. When a Blob value is loaded a ArrayStoreException is thrown because in 
> load(PropertyId id) BlobFileValues are added to internalValueList instead of 
> InternalValue instances.
> 10. in store(NodeReferences). When storing a NodeReferences which have some (but not
all) the references deleted the OJB persistence Manager doesn't delete any one.
> Some of this problems are present in the Hibernate implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message