[
https://issues.apache.org/jira/browse/OFBIZ-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677716#action_12677716
]
Jacques Le Roux commented on OFBIZ-2208:
----------------------------------------
If I remember well this (transactions with the same Timestamp) should not arise
if you are using PostGres or Derby but could happen with MySql. This is because
Postgres and Derby have milliseconds in Timestamps but [not
MySql|http://feedblog.org/2007/05/26/why-doesnt-mysql-support-millisecond-datetime-resolution/].
Moreover, IIRW, OFBiz is enforcing this to be sure to not have duplicates in
milliseconds.
There has been [such a question 2 years
ago|http://markmail.org/message/vqgcqdk7hnsjp3eo] but w/o a clear answer.
On my side I think your solution is a good one as we don't have to worry too
much for ServerHit duplicates. Moreover, this problem should only happen with
MySql hence this change should not have any impact for DBMS using milliseconds
in Timestamps. So if nobody sees a problem with that I will commit this
solution very soon.
> ServerHit aborts transactions when trying to create entries with duplicate
> startTime(s).
> ----------------------------------------------------------------------------------------
>
> Key: OFBIZ-2208
> URL: https://issues.apache.org/jira/browse/OFBIZ-2208
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk, Release Branch 4.0
> Environment: any
> Reporter: Karim Rahimpur
> Fix For: SVN trunk
>
> Attachments: ServerHitBin.java.patch
>
>
> org.ofbiz.webapp.stats.ServerHitBin.saveHit(...) causes transactions to be
> aborted due to duplicate PKs.
> The problem is that said method will try to create two or more entries with
> identical startTimes (i.e. duplicate hitStartDateTime and the other fields
> composing the PK: visitId, contentId, hitStartDateTime, hitTypeId) if two or
> more subsequent requests are made in a sufficiently small interval. This can
> and *will* be the case for example if an application rapidly issues requests
> for similar data. It would usually not be observed when human users cause
> requests being issued.
> The cause is that the above mentioned method uses
> serverHit.create();
> to store the entries.
> A solution to this is to _create or update_ an existing entry, thus
> overwriting an existing entry in case there already was an entry, but more
> importantly avoiding the actual transaction being aborted. This may not
> satisfy those who want to record each and every server hit even with equal
> startTimes. For these cases other approaches might be considered ...
> This is an example where a transaction fails due to saveHit(...). In our case
> an applet tries to pull data off the server and fails ...
> {panel}Failure in create operation for entity [ServerHit]:
> org.ofbiz.entity.GenericEntityException: Error while inserting:
> [GenericEntity:ServerHit][contentId,gdm.getProductFeatureApplAttrs(java.lang.String)][createdStamp,2009-02-24
> 10:34:29.454(java.sql.Timestamp)][createdTxStamp,2009-02-24
> 10:34:29.454(java.sql.Timestamp)][hitStartDateTime,2009-02-24
> 10:34:29.443(java.sql.Timestamp)][hitTypeId,REQUEST(java.lang.String)][lastUpdatedStamp,2009-02-24
> 10:34:29.454(java.sql.Timestamp)][lastUpdatedTxStamp,2009-02-24
> 10:34:29.454(java.sql.Timestamp)][partyId,KR(java.lang.String)][referrerUrl,(java.lang.String)][requestUrl,https://127.0.0.1:8443/gdm/control/getProductFeatureApplAttrs(java.lang.String)][runningTimeMillis,8(java.lang.Long)][serverHostName,Kitty(java.lang.String)][serverIpAddress,192.168.1.70(java.lang.String)][userLoginId,karim(java.lang.String)][visitId,11900(java.lang.String)]
> (SQL Exception while executing the following:INSERT INTO SERVER_HIT
> (VISIT_ID, CONTENT_ID, HIT_START_DATE_TIME, HIT_TYPE_ID, NUM_OF_BYTES,
> RUNNING_TIME_MILLIS, USER_LOGIN_ID, STATUS_ID, REQUEST_URL, REFERRER_URL,
> SERVER_IP_ADDRESS, SERVER_HOST_NAME, LAST_UPDATED_STAMP,
> LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP, INTERNAL_CONTENT_ID,
> PARTY_ID, ID_BY_IP_CONTACT_MECH_ID, REF_BY_WEB_CONTACT_MECH_ID) VALUES (?, ?,
> ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (Duplicate entry
> '11900-gdm.getProductFeatureApplAttrs-2009-02-24 10:34:29-REQUEST' for key
> 'PRIMARY')). Rolling back transaction.
> Exception: org.ofbiz.entity.GenericEntityException{panel}
> This issue seems to be related (it refers to the releae branch 4.0 and the
> same error shows up):
> [https://issues.apache.org/jira/browse/OFBIZ-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
