Rails 5.1.4 + psql, ActiveRecord bizarre double transaction BEGIN, when expecting one

What I thought was an issue with a rack-timeout setting is actually an issue with ActiveRecord::Base.transaction

When a request hits one of our update endpoints and that update is handled in a transaction

for even something as simple as

def update

  ActiveRecord::Base.transaction do

    @note.find(params[:id])

    @note.update(text: "foo")

  end

end

Our server logs look like the following:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

one would expect:

started /foo

BEGIN

UPDATE

COMMIT

Issue is then when a error happens all transactions are not being rolled back. Our Logs look like:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

ROLLBACK

Instead of:

started /foo

BEGIN

UPDATE

ROLLBACK

Weird part

In development mode when we edit any rails file in any way. The action works as expected with one BEGIN. On a restart of the server there are two BEGINs. Also this only happens when in a controller, not in console, not even calling the controller in the console. which can be done:

rails c

# app#action "path"

app.put "/foo"

This issue is present on a fresh start of a server(rails s), but if I edit any part of the code and rails reloads the code base the action acts as expected.

Also this is only happening though controllers, taking the same code block and sticking it in a resque job, it works as expected.

Calling the endpoint from the console app.put "/note" works as expected.

Calling note.update works as expected

Rspec controller and integration tests work as expected.

Note.transaction works as expected, though double BEGIN is still present in logs

Note.last.update works as expected, though double BEGIN is still present in logs

ActiveRecord::Base.transaction does NOT work as expected.

Rails 5.1.4

Has any one seen an issue like this before? Is the possibly a AR setting or maybe introduced from a gem?

In the request that has two begin blocks The first begin is the transaction that we are opening in the controller. SO where is the 2nd pre update coming from begin coming from?

UPDATE

I opened a issue on ActiveRecord here. I will summarize it here.

The reason I think this might, though loosely an AR issue is the fact the 2nd BEGIN is actually from update method which uses a transaction.

Stack traces from
lib/active_record/connection_adapters/postgresql/database_statements.rb:ln 130
I added an puts caller here for the last time it is being called before the update statement is called, in this case:

2 for our app
1 for the other rails app.

Our App

    active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction'

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

active_record/transactions.rb:381:in `with_transaction_returning_status'

active_record/persistence.rb:283:in `update'

app/controllers/debugging_transactions_controller.rb:18:in `block in update'

active_record/connection_adapters/abstract/database_statements.rb:235:in `block in transaction' <<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:194:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:12:in `update' #ActiveRecord::Base.transaction do

New Rails Application, with duplicate Gemfile and Gemfile.lock file.

active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction' <<<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:11:in `update' # ActiveRecord::Base.transaction do

Our app is hitting the update action of the persistance.rb which does wrap the action in a transaction
but why?

Update
I figured out the what but not the why.

https://github.com/rails/rails/blob/813af4655f9bf3c712cf50205eebd337070cee52/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb#L151
The 1nd time this is called in a normal rails app The transaction @stack.size is 0 and AR uses a RealTransaction which is joinable. which then in
https://github.com/rails/rails/blob/813af4655f9bf3c712cf50205eebd337070cee52/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb#L228

A RealTransaction is joinable and so rails runs the yield(your block)

In our application the stack size is zero and it is using a NullTransaction. Which is not joinable which then causes AR to wrap model.update aka with_transaction_returning_status in an entirely new transaction. Seems like this is a threading issue or perhaps a connection issue??

edited Jan 1 at 15:31

Cœur

18.7k9110150

asked Aug 20 '18 at 20:21

ChrisCPO

13512

add a comment |

What I thought was an issue with a rack-timeout setting is actually an issue with ActiveRecord::Base.transaction

When a request hits one of our update endpoints and that update is handled in a transaction

for even something as simple as

def update

  ActiveRecord::Base.transaction do

    @note.find(params[:id])

    @note.update(text: "foo")

  end

end

Our server logs look like the following:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

one would expect:

started /foo

BEGIN

UPDATE

COMMIT

Issue is then when a error happens all transactions are not being rolled back. Our Logs look like:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

ROLLBACK

Instead of:

started /foo

BEGIN

UPDATE

ROLLBACK

Weird part

rails c

# app#action "path"

app.put "/foo"

This issue is present on a fresh start of a server(rails s), but if I edit any part of the code and rails reloads the code base the action acts as expected.

Also this is only happening though controllers, taking the same code block and sticking it in a resque job, it works as expected.

Calling the endpoint from the console app.put "/note" works as expected.

Calling note.update works as expected

Rspec controller and integration tests work as expected.

Note.transaction works as expected, though double BEGIN is still present in logs

Note.last.update works as expected, though double BEGIN is still present in logs

ActiveRecord::Base.transaction does NOT work as expected.

Rails 5.1.4

Has any one seen an issue like this before? Is the possibly a AR setting or maybe introduced from a gem?

In the request that has two begin blocks The first begin is the transaction that we are opening in the controller. SO where is the 2nd pre update coming from begin coming from?

UPDATE

I opened a issue on ActiveRecord here. I will summarize it here.

The reason I think this might, though loosely an AR issue is the fact the 2nd BEGIN is actually from update method which uses a transaction.

2 for our app
1 for the other rails app.

Our App

    active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction'

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

active_record/transactions.rb:381:in `with_transaction_returning_status'

active_record/persistence.rb:283:in `update'

app/controllers/debugging_transactions_controller.rb:18:in `block in update'

active_record/connection_adapters/abstract/database_statements.rb:235:in `block in transaction' <<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:194:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:12:in `update' #ActiveRecord::Base.transaction do

New Rails Application, with duplicate Gemfile and Gemfile.lock file.

active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction' <<<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:11:in `update' # ActiveRecord::Base.transaction do

Our app is hitting the update action of the persistance.rb which does wrap the action in a transaction
but why?

Update
I figured out the what but not the why.

A RealTransaction is joinable and so rails runs the yield(your block)

edited Jan 1 at 15:31

Cœur

18.7k9110150

asked Aug 20 '18 at 20:21

ChrisCPO

13512

add a comment |

What I thought was an issue with a rack-timeout setting is actually an issue with ActiveRecord::Base.transaction

When a request hits one of our update endpoints and that update is handled in a transaction

for even something as simple as

def update

  ActiveRecord::Base.transaction do

    @note.find(params[:id])

    @note.update(text: "foo")

  end

end

Our server logs look like the following:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

one would expect:

started /foo

BEGIN

UPDATE

COMMIT

Issue is then when a error happens all transactions are not being rolled back. Our Logs look like:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

ROLLBACK

Instead of:

started /foo

BEGIN

UPDATE

ROLLBACK

Weird part

rails c

# app#action "path"

app.put "/foo"

This issue is present on a fresh start of a server(rails s), but if I edit any part of the code and rails reloads the code base the action acts as expected.

Also this is only happening though controllers, taking the same code block and sticking it in a resque job, it works as expected.

Calling the endpoint from the console app.put "/note" works as expected.

Calling note.update works as expected

Rspec controller and integration tests work as expected.

Note.transaction works as expected, though double BEGIN is still present in logs

Note.last.update works as expected, though double BEGIN is still present in logs

ActiveRecord::Base.transaction does NOT work as expected.

Rails 5.1.4

Has any one seen an issue like this before? Is the possibly a AR setting or maybe introduced from a gem?

In the request that has two begin blocks The first begin is the transaction that we are opening in the controller. SO where is the 2nd pre update coming from begin coming from?

UPDATE

I opened a issue on ActiveRecord here. I will summarize it here.

The reason I think this might, though loosely an AR issue is the fact the 2nd BEGIN is actually from update method which uses a transaction.

2 for our app
1 for the other rails app.

Our App

    active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction'

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

active_record/transactions.rb:381:in `with_transaction_returning_status'

active_record/persistence.rb:283:in `update'

app/controllers/debugging_transactions_controller.rb:18:in `block in update'

active_record/connection_adapters/abstract/database_statements.rb:235:in `block in transaction' <<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:194:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:12:in `update' #ActiveRecord::Base.transaction do

New Rails Application, with duplicate Gemfile and Gemfile.lock file.

active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction' <<<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:11:in `update' # ActiveRecord::Base.transaction do

Our app is hitting the update action of the persistance.rb which does wrap the action in a transaction
but why?

Update
I figured out the what but not the why.

A RealTransaction is joinable and so rails runs the yield(your block)

edited Jan 1 at 15:31

Cœur

18.7k9110150

asked Aug 20 '18 at 20:21

ChrisCPO

13512

What I thought was an issue with a rack-timeout setting is actually an issue with ActiveRecord::Base.transaction

When a request hits one of our update endpoints and that update is handled in a transaction

for even something as simple as

def update

  ActiveRecord::Base.transaction do

    @note.find(params[:id])

    @note.update(text: "foo")

  end

end

Our server logs look like the following:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

one would expect:

started /foo

BEGIN

UPDATE

COMMIT

Issue is then when a error happens all transactions are not being rolled back. Our Logs look like:

started /foo

BEGIN

BEGIN

UPDATE

COMMIT

ROLLBACK

Instead of:

started /foo

BEGIN

UPDATE

ROLLBACK

Weird part

rails c

# app#action "path"

app.put "/foo"

This issue is present on a fresh start of a server(rails s), but if I edit any part of the code and rails reloads the code base the action acts as expected.

Also this is only happening though controllers, taking the same code block and sticking it in a resque job, it works as expected.

Calling the endpoint from the console app.put "/note" works as expected.

Calling note.update works as expected

Rspec controller and integration tests work as expected.

Note.transaction works as expected, though double BEGIN is still present in logs

Note.last.update works as expected, though double BEGIN is still present in logs

ActiveRecord::Base.transaction does NOT work as expected.

Rails 5.1.4

Has any one seen an issue like this before? Is the possibly a AR setting or maybe introduced from a gem?

In the request that has two begin blocks The first begin is the transaction that we are opening in the controller. SO where is the 2nd pre update coming from begin coming from?

UPDATE

I opened a issue on ActiveRecord here. I will summarize it here.

The reason I think this might, though loosely an AR issue is the fact the 2nd BEGIN is actually from update method which uses a transaction.

2 for our app
1 for the other rails app.

Our App

    active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction'

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

active_record/transactions.rb:381:in `with_transaction_returning_status'

active_record/persistence.rb:283:in `update'

app/controllers/debugging_transactions_controller.rb:18:in `block in update'

active_record/connection_adapters/abstract/database_statements.rb:235:in `block in transaction' <<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:194:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:12:in `update' #ActiveRecord::Base.transaction do

New Rails Application, with duplicate Gemfile and Gemfile.lock file.

active_record/connection_adapters/abstract/transaction.rb:130:in `initialize'

active_record/connection_adapters/abstract/transaction.rb:156:in `new'

active_record/connection_adapters/abstract/transaction.rb:156:in `block in begin_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:152:in `begin_transaction' <<<<<<<<<

active_record/connection_adapters/abstract/transaction.rb:193:in `block in within_new_transaction'

monitor.rb:226:in `mon_synchronize'

active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'

active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'

active_record/transactions.rb:210:in `transaction'

app/controllers/debugging_transactions_controller.rb:11:in `update' # ActiveRecord::Base.transaction do

Our app is hitting the update action of the persistance.rb which does wrap the action in a transaction
but why?

Update
I figured out the what but not the why.

A RealTransaction is joinable and so rails runs the yield(your block)

ruby-on-rails activerecord psql puma

edited Jan 1 at 15:31

Cœur

18.7k9110150

asked Aug 20 '18 at 20:21

ChrisCPO

13512

edited Jan 1 at 15:31

Cœur

18.7k9110150

asked Aug 20 '18 at 20:21

ChrisCPO

13512

edited Jan 1 at 15:31

Cœur

18.7k9110150

edited Jan 1 at 15:31

Cœur

18.7k9110150

edited Jan 1 at 15:31

Cœur

18.7k9110150

asked Aug 20 '18 at 20:21

ChrisCPO

13512

asked Aug 20 '18 at 20:21

ChrisCPO

13512

asked Aug 20 '18 at 20:21

ChrisCPO

13512

add a comment |

1 Answer
1

active

oldest

votes

So I Figured this out. It was a puma worker configuration which was I believe was causing weird thread/ double connection issues.

In our config/puma.rb file we had

on_worker_boot do

  ApplicationRecord.establish_connection if defined?(ActiveRecord)

end

Changing it to this fixed the issue.

on_worker_boot do

  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

end

Odd that ApplicationRecord#establish_connection != ActiveRecord::Base#establish_connection

answered Sep 7 '18 at 13:42

ChrisCPO

13512

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51937999%2frails-5-1-4-psql-activerecord-bizarre-double-transaction-begin-when-expectin%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

So I Figured this out. It was a puma worker configuration which was I believe was causing weird thread/ double connection issues.

In our config/puma.rb file we had

on_worker_boot do

  ApplicationRecord.establish_connection if defined?(ActiveRecord)

end

Changing it to this fixed the issue.

on_worker_boot do

  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

end

Odd that ApplicationRecord#establish_connection != ActiveRecord::Base#establish_connection

answered Sep 7 '18 at 13:42

ChrisCPO

13512

add a comment |

So I Figured this out. It was a puma worker configuration which was I believe was causing weird thread/ double connection issues.

In our config/puma.rb file we had

on_worker_boot do

  ApplicationRecord.establish_connection if defined?(ActiveRecord)

end

Changing it to this fixed the issue.

on_worker_boot do

  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

end

Odd that ApplicationRecord#establish_connection != ActiveRecord::Base#establish_connection

answered Sep 7 '18 at 13:42

ChrisCPO

13512

add a comment |

So I Figured this out. It was a puma worker configuration which was I believe was causing weird thread/ double connection issues.

In our config/puma.rb file we had

on_worker_boot do

  ApplicationRecord.establish_connection if defined?(ActiveRecord)

end

Changing it to this fixed the issue.

on_worker_boot do

  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

end

Odd that ApplicationRecord#establish_connection != ActiveRecord::Base#establish_connection

answered Sep 7 '18 at 13:42

ChrisCPO

13512

So I Figured this out. It was a puma worker configuration which was I believe was causing weird thread/ double connection issues.

In our config/puma.rb file we had

on_worker_boot do

  ApplicationRecord.establish_connection if defined?(ActiveRecord)

end

Changing it to this fixed the issue.

on_worker_boot do

  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

end

Odd that ApplicationRecord#establish_connection != ActiveRecord::Base#establish_connection

answered Sep 7 '18 at 13:42

ChrisCPO

13512

answered Sep 7 '18 at 13:42

ChrisCPO

13512

answered Sep 7 '18 at 13:42

ChrisCPO

13512

answered Sep 7 '18 at 13:42

ChrisCPO

13512

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu