Right. Thanks again for reporting that!
Should be fixed now.
Oliver
2006/1/13, Joerg Heinicke <[EMAIL PROTECTED]>:
> Oliver Zeigermann gmail.com> writes:
>
> > See my latest commit for an - hopefully - acceptable degree of
> > certainty that the id really is unique.
>
> Hello Oliver,
>
> I revi
Oliver Zeigermann gmail.com> writes:
> See my latest commit for an - hopefully - acceptable degree of
> certainty that the id really is unique.
Hello Oliver,
I reviewed the changes in commons-transaction since 1.1. And I want to come back
to this old thread [1]. Your commit is at [2]. I wonder
See my latest commit for an - hopefully - acceptable degree of
certainty that the id really is unique. In the - very unlikely - case
that it really is not unique you can still catch the exception when
starting the tx and retry with a new one.
Acceptable?
Oliver
2005/11/23, Oliver Zeigermann <[EM
2005/11/23, Joerg Heinicke <[EMAIL PROTECTED]>:
> Oliver Zeigermann gmail.com> writes:
>
> > To me it seems generatedUniqueTxId does exactly as advertised in
> > Javadocs. Don't you agree?
>
> No. :) This dismisses my argument about externally generated ids, yes. But two
> different threads callin
Oliver Zeigermann gmail.com> writes:
> To me it seems generatedUniqueTxId does exactly as advertised in
> Javadocs. Don't you agree?
No. :) This dismisses my argument about externally generated ids, yes. But two
different threads calling generateUniqueTxId() at the same time still get the
same "
Cool.
Oliver
2005/11/22, Cservenak Tamas <[EMAIL PROTECTED]>:
> Hi,
>
> thank you for response. Jorg already convinced me to use some external Id
> generator, and not the handy built in (which was a handy solution for fast
> jump-in).
>
> My "patch" for generatedTxId will be simply moved to my
Hi,
thank you for response. Jorg already convinced me to use some external
Id generator, and not the handy built in (which was a handy solution
for fast jump-in).
My "patch" for generatedTxId will be simply moved to my code and it
will do the trick, as it solves my problem.
Thank you for hel
To me it seems generatedUniqueTxId does exactly as advertised in
Javadocs. Don't you agree?
You simply need something different as it seems. Unique Id generators
- that's what you need - are easy to find, even in the Jakarta Commons
Project :)
Oliver
2005/11/22, Cservenak Tamas <[EMAIL PROTECTED
Yes, youre right.
Anyway, in my case it would be more appropriate to generate Tx ID's by
myself to avoid generatedUniqueTxId() problem. As first step i will
probably copy this patched method into my code and use it instead of
calling frm.generated
Thanks for help. And sorry for bothering,
Cservenak Tamas is-micro.hu> writes:
> The generatedUniqueTxId() method in FileResourceManager uses
> System.currentTimeMillis() to generate txId's.
>
> On my system it causes duplicate txId generation and FRM failure. I have
> 4 threads accessing one FRM instance.
>
> This simple patch adds "s
Hi all!
The generatedUniqueTxId() method in FileResourceManager uses
System.currentTimeMillis() to generate txId's.
On my system it causes duplicate txId generation and FRM failure. I have
4 threads accessing one FRM instance.
This simple patch adds "salt" to it, with a little overhead to solve
11 matches
Mail list logo
