it potentially mess up PK generation? I thought it should not,
but of course, as so often, I can be wrong.
I think that switching to pessimistic locking will help this situation
Originally, we have used pessimistic locking, but we have found it gets a bit
slow. Correct me please if I am overlooking
On 2015-05-17, 3:19 AM, ocs.cz wrote:
Chuck,
On 14 5 2015, at 2:22 am, Chuck Hill
ch...@gevityinc.commailto:ch...@gevityinc.com wrote:
FrontBase will return the sequence number if the transaction is rolled back,
but I am pretty sure that EOF does a commit immediately after selecting for a
PK.
Chuck,
On 19 5 2015, at 11:13 pm, Chuck Hill ch...@gevityinc.com wrote:
Well then, what if I, at the moment any EO gets inserted into an EC,
immediatelly called permanentGlobalID for it?
The original problem was caused, as best I can call, by FrontBase vending the
same sequence number
Turn on SQL logging and see what happens. I don't recall if the Pks are
generated in their own transaction or as part of the saveChanges() transaction.
If they are generated and committed in their own transaction (which is my
guess), then your proposal won't help.
Chuck
On 2015-05-19, 2:24
Samuel,
On 14 5 2015, at 2:12 am, Samuel Pelletier sam...@samkar.com wrote:
I think your problem is with the locking. Optimistic locking does not lock
anything it check on commit if things have changed.
Right; but does it potentially mess up PK generation? I thought it should
Chuck,
On 14 5 2015, at 2:22 am, Chuck Hill ch...@gevityinc.com wrote:
FrontBase will “return” the sequence number if the transaction is rolled
back, but I am pretty sure that EOF does a commit immediately after selecting
for a PK.
It is possible that somehow the commit after the PK
Samuel,
On 14 5 2015, at 2:30 pm, Samuel Pelletier sam...@samkar.com wrote:
I just tested with my local FB 5.2.14 and it behave like oracle, the current
transaction state or setting does not affect the unique sequence, it always
increments and return the next value.
OC, I suggest you
Chuck,
I used FrontBase Manager with 2 connections with these setting and discrete
commits.
set transaction isolation level read committed, locking optimistic, read write;
I tried different rollback scenarios but the sequence was always correct. I
used FB 5.2.14 on OS X with a database created
In FB, they used to be inside the transaction (If I remember correctly) and
with Read Committed locking optimistic, the server to return the same value to
both connections if the second select overlaps the first.
I just tested with my local FB 5.2.14 and it behave like oracle, the current
Hi Samuel,
What did you do to test FrontBase? I tried this in FrontBaseManager with
“discrete commit” and rolling back the transaction, caused the sequence numbers
generated to be generated again in the next transaction. If you commit (or
auto commit) then it behaves as you describe. It
OC,
I think your problem is with the locking. Optimistic locking does not lock
anything it check on commit if things have changed.
I think that switching to pessimistic locking will help this situation for a
multiple instance setup, the sequence will be locked for the remaining
transaction
It depends on the database. The Oracle sequence generation is outside of the
ACID transaction and is not affected by transactions or commits. Once Oracle
has returned a number from a sequence it won’t do so again* regardless of any
transactions getting rolled back or committed.
* assuming
Chuck,
On 12. 5. 2015, at 23:09, Chuck Hill ch...@gevityinc.com wrote:
You really do come up with the absolute best problems! :-)
Well it's great if one's best in something, is it not? ;)
My guess is that somehow the database failed to record the update to the
sequence number. Every
Samuel,
On 12. 5. 2015, at 23:49, Samuel Pelletier sam...@samkar.com wrote:
Sequence generation for concurrent access may be tricky to do right,
especially if the system is tuned for performance. There is a confrontation
between the sequence integrity and the concurrent access. It is easy
On 2015-05-13, 9:56 AM, OC wrote:
Chuck,
On 12. 5. 2015, at 23:09, Chuck Hill
ch...@gevityinc.commailto:ch...@gevityinc.com wrote:
You really do come up with the absolute best problems! :-)
Well it's great if one's best in something, is it not? ;)
True that!
My guess is that somehow the
You really do come up with the absolute best problems! :-)
www.youtube.com/watch?v=otCpCn0l4Wo
My guess is that somehow the database failed to record the update to the
sequence number. Every time you ran it after that, it generated the used one
and then failed. When you added logging,
Hello there,
my application, among others, generates and stores audit records. The
appropriate code is comparatively straightforward; it boils down to something
like
===
... ec might contain unsaved objects at this moment ...
DBAudit audit=new DBAudit()
ec.insertObject(audit)
Sequence generation for concurrent access may be tricky to do right, especially
if the system is tuned for performance. There is a confrontation between the
sequence integrity and the concurrent access. It is easy to use a sequence
table wrong...
OC, which database are you using with which
Hi,I have a weird case where EOF fails to include the primary key with an INSERT, but not every time. The model of the EO in question looks like this: The linkKey column is actually new. I discovered that the primary key before was (journeyElementRef,workflow) which lead to other problems I needed
Hi Maik,
as this table seems to be a join-table chances are high that on the
relationships to that table in your EOModel you still have „Propagate primary
key“ active if Entity Modeler did create that table.
jw
Am 07.02.2014 um 11:37 schrieb Musall Maik m...@selbstdenker.ag:
Hi,
I have
Hi Johann,
100% hit. I owe you a beer :-)
Maik
Am 07.02.2014 um 11:44 schrieb Johann Werner j...@oyosys.de:
Hi Maik,
as this table seems to be a join-table chances are high that on the
relationships to that table in your EOModel you still have „Propagate primary
key“ active if Entity
Fixed in the new 5.4.3 release:
6116393 Race Condition with Primary Key Generationin FrontBase JDBC
Plugin
Chuck
On Sep 14, 2008, at 10:24 PM, Andrew Lindesay wrote:
Hello;
I found this bug in 5.4.2 and have reported it already. Use the
ProjectWonder FrontBase EOF plugin in the
Hi Ondra
I once had a similar problem using automatic PK generation with
OpenBase - and discovered that the table in question only had a
'normal' index set on the primary key field rather than a 'unique'
index. I don't know if Frontbase creates indexes in the same way,
but if so
On 10.09.08 09:06, Ondřej Čada [EMAIL PROTECTED] wrote:
someone who understands how exactly does EOF generate PK's with
FrontBase and the default setup (PK's generated automatically) -- any
idea whether (and if so, why) a duplicated PK can be generated?
Inserting data in the table without
Guido,
On Sep 10, 2008, at 5:42 PM, Guido Neitzer wrote:
someone who understands how exactly does EOF generate PK's with
FrontBase and the default setup (PK's generated automatically) -- any
idea whether (and if so, why) a duplicated PK can be generated?
Inserting data in the table without
On 10/09/08 10:03 AM, Ondřej Čada [EMAIL PROTECTED] wrote:
Well, thanks... and do you please have any idea what might cause
inserting data without using ... etc.?
Not using the FrontBasePlugIn or using something different than WebObjects
to insert like FrontBaseManager or whatever other tool.
On 10/09/08 10:58 AM, Ondřej Čada [EMAIL PROTECTED] wrote:
Me too; that's why I am that surprised seeing the duplicated PK
problem :-O
I remember having heard of something like that happening when FrontBase
crashed or got bad data somehow. Which version of FB are you using?
We had a database
Guido,
On 10.9.2008, at 19:14, Guido Neitzer wrote:
I remember having heard of something like that happening when
FrontBase
crashed or got bad data somehow. Which version of FB are you using?
A pretty recent one, let me see what the client has... 4.4.10.
We had a database here that was
Randy,Generally PK generation is a function EOF not MySQL. There are plug-ins that support database native PK generation, as is the case with "OpenBasePKPlugIn." but I'm not aware of anything similar for MySQL.In any case, unless you're using something special, this problem likely h
up to maybe.. 0.03
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Walker
Sent: Thursday, May 18, 2006 2:24
PM
To: Development WebObjects
Subject: Re: PK Generation in
MySQL
Randy,
Generally PK generation is a function EOF not MySQL. There are
plug-ins
of database tuning we decided to try OpenBase. Obviously, we would have liked to use MySQL for cost reasons, but just couldn't get the needed performance.In fact (as I now recall) we had a very similar problem. I don't believe ours was with PK generation, but we were getting some duplicate entries
.
And performance and conformance to standards. Yes, FrontBase is now
free.
Chuck
In fact (as I now recall) we had a very similar problem. I don't
believe ours was with PK generation, but we were getting some
duplicate entries in the database due to race conditions on the
inserts. In our case we
Am 18.05.2006 um 20:24 schrieb Robert Walker:
Generally PK generation is a function EOF not MySQL. There are
plug-ins that support database native PK generation, as is the case
with OpenBasePKPlugIn. but I'm not aware of anything similar for
MySQL.
In any case, unless you're using
Can you give any hints about how you wrapped the PK Gen?
The easiest way I see is to let MySQL generate the keys itself. How could I
go about that? Ie, create table myTable (id int not null auto_increment,
other cols) and then turn off EOF PK generation. Does that seem like a good
alternative
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Anjo Krank
Sent: Thursday, May 18, 2006 3:03 PM
To: Robert Walker
Cc: Development WebObjects
Subject: Re: PK Generation in MySQL
Am 18.05.2006 um 20:24 schrieb Robert Walker:
Generally PK generation is a function EOF not MySQL
The easiest way I see is to let MySQL generate the keys itself.
How could I
As far as I know you cannot let MySQL generate the keys itself, at
least not in the way you're probably thinking. I really don't think
EOF has any support for native PK generation with MySQL.
On May 18, 2006
In fact (as I now recall) we had a very similar problem. I don't
believe ours was with PK generation, but we were getting some
duplicate entries in the database due to race conditions on the
inserts. In our case we had to catch the exception and recover by
making a second attempt
, Anjo Krank wrote:
Am 18.05.2006 um 20:24 schrieb Robert Walker:
Generally PK generation is a function EOF not MySQL. There are
plug-ins that support database native PK generation, as is the
case with OpenBasePKPlugIn. but I'm not aware of anything
similar for MySQL.
In any case, unless
38 matches
Mail list logo
