Created: (JCR-2905) DateFormat.getDateTimeInstance() is very expensive, we can cache it to improve performance

DateFormat.getDateTimeInstance() is very expensive, we can cache it to improve performance
------------------------------------------------------------------------------------------
Key: JCR-2905
URL: https://issues.apache.org/jira/browse/JCR-2905
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2.2
Reporter: Xiaoming Shi
DateFormat.getDateTimeInstance() is very expensive, we can cache it to improve performance
In the
file:
./jackrabbit-2.2.2/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/observation/EventJournalImpl.java
line: 356
DateFormat.getDateTimeInstance() is called in a critical section. We can move it outside the critical
section to increase the concurrency. It's better for us to add a class member field to store the value.
This is similar to the Apache bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=48778

Updated: (JCR-2905) DateFormat.getDateTimeInstance() is very expensive, we can cache it to improve performance

[
https://issues.apache.org/jira/browse/JCR-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller updated JCR-2905:
--------------------------------
Priority: Minor (was: Major)
Issue Type: Wish (was: Bug)
DateFormat.getDateTimeInstance() is only used if the log level is set to debug:
if (log.isDebugEnabled()) {
DateFormat df = DateFormat.getDateTimeInstance();
...
}
Do you really need to set the log level to debug?
Please note that DateFormat.format would need to be synchronized. Possibly a simpler solution would be:
new java.sql.Timestamp(timestamp.longValue()).toString()
However I'm not sure if this would work correctly (UTF versus local time zone).
> DateFormat.getDateTimeInstance() is very expensive, we can cache it to improve performance
> ------------------------------------------------------------------------------------------
>
> Key: JCR-2905
> URL: https://issues.apache.org/jira/browse/JCR-2905

Created: (JCR-2906) Multivalued property sorted incorrectly

Paul Lysak (JIRA <jira <at> apache.org>
2011-03-01 15:33:36 GMT

Multivalued property sorted incorrectly
---------------------------------------
Key: JCR-2906
URL: https://issues.apache.org/jira/browse/JCR-2906
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2.0
Environment: Windows 7, Sun JDK 1.6.0_23
Reporter: Paul Lysak
Sorting on multivalued property may produce incorrect result because sorting is performed only by last
value of multivalued property.
Steps to reproduce:
1. Create multivalued field in repository. Example from nodetypes file:
<propertyDefinition name="MyProperty" requiredType="String" autoCreated="false" mandatory="false"
onParentVersion="COPY" protected="false" multiple="false">
2. Create few records so that all records except one would contain single value for MyProperty and one
record would contain
first value which is greater then of any other record and the second value is somewhere in the middle. Here is
an example:
1st record: "aaaa"
2nd record: "cccc"
3rd record: "dddd", "bbbb"
3. Run some query which sorts Example of XPath query:
//*[...here are some criteria...] order by <at> MyProperty ascending
The query would return documents in such order:
"aaaa"
"dddd", "bbbb"

Updated: (JCR-2906) Multivalued property sorted by last/random value

[
https://issues.apache.org/jira/browse/JCR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Klimetschek updated JCR-2906:
---------------------------------------
Issue Type: Improvement (was: Bug)
Summary: Multivalued property sorted by last/random value (was: Multivalued property sorted incorrectly)
> which is not expected order (expected same order as they were entered ...)
But when you specify "order by <at> MyProperty ascending" you explicitly want to order by the property, not the
document order.
AFAICS the JCR 1.0 and 2.0 spec don't define any behavior for comparing single-value properties to
multi-value ones (or mv to mv), so I think the repository implementation is free to chose the most
efficient one. Hence this is not a bug.
Also, it is not clear how to define an ordering upon multi-value properties at all: Compare against the
concatenation of the string representations of all the values in the property? Or compare against the
first value?
> Multivalued property sorted by last/random value
> ------------------------------------------------
>
> Key: JCR-2906
> URL: https://issues.apache.org/jira/browse/JCR-2906
> Project: Jackrabbit Content Repository
> Issue Type: Improvement

can't get versionable node's child property after restore within transaction
----------------------------------------------------------------------------
Key: JCR-2907
URL: https://issues.apache.org/jira/browse/JCR-2907
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2.0
Environment: WIN XP
JDK 1.6
JBOSS 4.2
Reporter: codeparser
The case is as follows:
1. create a versionable node named "folder" and create five child and add some property to the children.
2. checkout the node "folder", and add a new child, and then save
3. begin a transaction
4. get a new jackrabbit session
5. get the node "folder", and restore to its base version
6. get "folder"'s child, all the children could be getton, but the children's property lost.
but after commit the transaction, the content in the database is corret.
7.commit transaction