[ 
https://issues.apache.org/jira/browse/OFBIZ-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189718#comment-14189718
 ] 

Jacques Le Roux commented on OFBIZ-2208:
----------------------------------------

That's indeed a good point Ingo. We could then close this issue, what do others 
think?

> 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: Release Branch 4.0, Trunk
>         Environment: any
>            Reporter: Karim Rahimpur
>            Assignee: Jacques Le Roux
>         Attachments: ServerHit.patch, ServerHitBin.java.patch, 
> ServerHitBin.patch, SynchronizedHitBin.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 was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to