[Vtigercrm-developers] Duplicate CRMIDs 5.40

Stefan Warnat ich at stefanwarnat.de
Wed Jan 8 13:32:32 GMT 2014


Oh.I'm not along. That's good (or bad).

Normally you don't get any problems, because "created time" is equal and
the wrong modified time won't be recognized by anybody, I think.
You could edit the record without any problems and delete, too. The second
record, which disappear will be recognized mostly after a long time and
taken in the box "employee are idiots, why they delete this"
But I use the Webservice as Layer between my Extensions and the vtiger. And
they will check if the ModuleName I submit is equal to setype in database.

@Michael: Connection pooling could really cause problems, like I read in
the web. But was not the problem in my case.

*The Question I have for the vtigerCRM developers: Won't it be better to
use AutoIncrement for crmid column?* I think the DBMS could handle multiple
access at the same time very well.
All "big" DBMS will support this. (PostgreSQL, MSSQL, MySQL, Oracle,
SQlite) Did anybody use another one?

Stefan


On Wed, Jan 8, 2014 at 2:05 PM, Joe Bordes <joe at tsolucio.com> wrote:

>  I agree, I had noticed this also although we haven't run into the
> problem either (at least that we know of).
>
> +1
>
>
> On 08/01/14 13:48, Zygmuntowicz Michal wrote:
>
> I did not hit this problem (or maybe I just did not notice it), but
> recently I took a look
> at the adodb library GenID function that creates unique IDs for sequences
> and for me it seems
> that this function may not be safe under some circumstances.
>
> Most objects use the singleton instance of the global $adb PearDatabase
> object.
> 1. The genID function of the underlaying adodb object is not thread safe,
> as it uses
>    $this->genID to store intermediate result and return it upon function
> exit.
>    But this should not be an issue, as script execution is single-threaded
> and each
>    HTTP request will get its own $adb object.
> 2. The genID function is using last_insert_id, which works only if the
> database connection
>     is used only by a single script and single thread. I don't know what
> happens
>     if the web server uses connection pooling. Maybe it is possible that
> the same database
>     connection is shared between concurrent HTTP requests and therefore
> last_insert_id
>     may return incorrect values.
> 3. I am not sure if the sequence tables should be locked - I guess
> autoincrement columns
>     should be transaction safe.
>
> These are only my thoughts - I think someone with good understanding of
> the web server/mysql/php
> interactions should throw some light on this.
>
>  *From:* Stefan Warnat <ich at stefanwarnat.de>
> *Sent:* Wednesday, January 08, 2014 12:05 PM
> *To:* vtigercrm-developers at lists.vtigercrm.com
> *Subject:* [Vtigercrm-developers] Duplicate CRMIDs 5.40
>
>  Hy,
>
>  Yesterday I found a very strange situation in one of my clients vtiger
> 5.4 systems.
> The System ~250k records contains Leads with a leadid, which isn't a
> "setype LEAD" in vtiger_crmentity.
> Some are Contacts, other Accounts, Tickets, ...
> Also the ID exist correctly in the respective tables of contacts,
> accounts, ...
>
>  I create the following problem situation:
> Two records are created in absolutely the same moment. (The createdtime
> column is completely equal)
> Because ADODB don't lock the sequence table, there could be a chance of
> duplicate crmid's, I suspect.
> I'm not fully sure how safe the used "LAST_INSERT_ID(id+1)" is.
> The normal "LAST_INSERT_ID()" is per connection, but only get back a auto
> increment.
>
>  Anyone other with this problem?
>
>  Stefan
>
>  ------------------------------
> _______________________________________________
> http://www.vtiger.com/
>
> _______________________________________________http://www.vtiger.com/
>
>
>
> --
> Un saludo
> Joe
> TSolucio
>
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140108/7ea1f80f/attachment-0001.html>


More information about the vtigercrm-developers mailing list