【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/04/11(月) 16:28:34.52

pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&;lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 3【io.js】(c)2ch.net
http://echo.2ch.net/test/read.cgi/tech/1419673207/
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/

**デフォルトの名無しさん** · 2017/07/10(月) 13:43:08.24

>>691
koaってexpressのミドルウェア使えたはず。
だからエコシステム的には問題ない。
とは言えasync-awaitもところどころ詰まるところはあるのは分かる
(例えばarrayのmapに渡す関数としては使えないとか。)

でも今から使うならkoaの方かな。

**デフォルトの名無しさん** · 2017/07/10(月) 13:46:50.96

expressのミドルウェア使うならexpressでええやん

**デフォルトの名無しさん** · 2017/07/10(月) 14:16:11.77

>>693
非同期処理を同期的にかける魅力には勝てない。

**デフォルトの名無しさん** · 2017/07/10(月) 14:57:56.02

691に戻る

**デフォルトの名無しさん** · 2017/07/10(月) 16:33:23.58

ｆ

**デフォルトの名無しさん** · 2017/07/10(月) 17:53:20.41

>>692
array.mapに非同期関数渡したいならrxjsで処理してtoPromiseすればおｋ

**デフォルトの名無しさん** · 2017/07/10(月) 18:48:24.41

>>697
いや。そもそもPromise.Allがmapと同義じゃんってわかったから
あえてrxjsは使わなくてもok

**デフォルトの名無しさん** · 2017/07/10(月) 19:17:56.48

まっ　CORE　ASP使っている身としては、koa2で十分なんだが、JadeからPugへの変更って必要だったのかえぇ～？　いまいちのような感じかする。
軽いCMSにkoa2は便利。　重いのもいけそうではあるが・・・

**デフォルトの名無しさん** · 2017/07/10(月) 19:26:02.76

>>699
jadeもpugも一緒だぞ
商標の問題で名前変えただけで

**デフォルトの名無しさん** · 2017/07/11(火) 16:15:40.20

koa2ってなに？koa.jsのこと？

**デフォルトの名無しさん** · 2017/07/11(火) 17:21:49.33

koe.js v2

**デフォルトの名無しさん** · 2017/07/11(火) 17:22:14.73

x koe.js v2
o koa.js v2

**デフォルトの名無しさん** · 2017/07/11(火) 23:24:55.50

あんましexpressもkoaも使ってるぜーって情報発信してる人いない気がする。
知らないうちにブロだクションで動いてるんかな

**デフォルトの名無しさん** · 2017/07/11(火) 23:54:59.61

expressってwebアプリケーションフレームワークって感じじゃないからな
rubyでいえばrack相当でrails相当じゃないから表に出ない

**デフォルトの名無しさん** · 2017/07/12(水) 00:05:15.88

expressはnode.js標準に付いていてもおかしくない程度の軽いフレームワークだしな

**デフォルトの名無しさん** · 2017/07/12(水) 01:08:53.04

ぶっちゃけ、express使うような案件だとphpでよくない？っておもっちゃう

**デフォルトの名無しさん** · 2017/07/12(水) 01:23:02.63

socket.ioとか使いたいからそれはないな

**デフォルトの名無しさん** · 2017/07/12(水) 03:27:41.84

>>708
おれもゲームサーバーでnode+socket.io使ってるけど、expressで配信するコンテンツってphpでよくね？ってパターン多い気がする
どうしても非同期じゃないと無理ってパターン以外は非同期のデメリットがでかすぎる
とくにDBがらみの単純な登録画面とかね
phpの数倍の開発コストかかるよ

**デフォルトの名無しさん** · 2017/07/12(水) 04:17:22.08

expressでdbアクセスなんてしてないな
bffとして使ってるから
node/expressの後ろのapi鯖はphpだったりrailsだったりjavaだったり

**デフォルトの名無しさん** · 2017/07/12(水) 04:21:26.67

>>710
ああ、そういう二段構えならokだね

**デフォルトの名無しさん** · 2017/07/12(水) 07:31:45.77

でもphpって1requestが1プロセスで高コストだから同時接続数を稼ごうと思ったらnode.jsの方が良いんじゃないの？dbがボトルネックだから気にする必要はない？

**デフォルトの名無しさん** · 2017/07/12(水) 07:33:23.93

それにasync awaitつかえば非同期処理はかなり自然に書けないかな？
学習コストは高くなるかもだけど

**デフォルトの名無しさん** · 2017/07/12(水) 08:32:57.14

async/await使いたいけど、LTSになるまで待ってって言われてる(´･ω･`)
TypeScriptはコンパイルしたくないって言われた、、、

**デフォルトの名無しさん** · 2017/07/12(水) 08:35:16.60

最終的にはアクセス増えたときのパフォーマンスの話になるんだろうけどそんなこと気にするレベルじゃない案件でわざわざ苦労してまでexpressでがんばる必要はないなと思う
必要な場面で局所的に使うのがnodeっていうイメージ

**デフォルトの名無しさん** · 2017/07/12(水) 11:37:51.18

phpだってさすがにスレッドぐらい使えるだろう

**デフォルトの名無しさん** · 2017/07/12(水) 14:22:08.20

非同期DB使えよ

**デフォルトの名無しさん** · 2017/07/12(水) 15:54:06.61

>>716
むっちゃしんどかった。
goを学習してgorutineで書き直したわ。

**デフォルトの名無しさん** · 2017/07/24(月) 09:12:28.43

express-resourceを使ってAPIサーバーを作りたいって考えているのですが
データベースへのアクセス手順を共通化したくなり、下記のようにしました。

class dbaccess {
　constructor(db) {
　　this.db = db
　}
　index(req, res, next) {
　　console.log(this) // undefined
　　this.db.find({}, (e,r)=>res.json(r))
　}
　// 以下略
}

app.use('users', new dbaccess(db))

1 APIクライアントからの GET /
-> this が undefined になっていてエラーになる

2 下記のコードからのindex()呼び出し
var dba = new dbaccess(db)
dba.index(null, null)
-> thisの内容が表示される

何か上手い解決策はないでしょうか。

**デフォルトの名無しさん** · 2017/07/24(月) 10:45:49.25

constructor内で
this.index.bind(this)でthisの束縛をすれば解決しませんか？

**デフォルトの名無しさん** · 2017/07/24(月) 15:05:38.54

うむ

**デフォルトの名無しさん** · 2017/07/24(月) 17:23:58.44

>>720
お答えいただきありがとうございます。
それを全部のメソッドにやるのも何かしっくりこないので、

下のようにクロージャにしてしまったら何とか期待する動作になりました。

function dbaccess(db) {
　let _db = db;
　return {
　　index(req, res) {
　　}
　　// 以下略
　}
}

クラスだと上手くいかないのがイマイチ納得できてませんけど。

**デフォルトの名無しさん** · 2017/07/25(火) 06:14:42.65

>>722
それが問題ならアロー関数をつかえば解決します。自動でthisを固定するんで。

**デフォルトの名無しさん** · 2017/07/25(火) 21:46:43.91

>>719
おいおい、変なことしないほうが良いぞ
もうちょっと調べるべきだろ？

他のプロジェクトでそんな書き方してるか？
昔やったきりで忘れたし今のやり方は変わってるかもしれないから
適切なアドバイスはできないがよ、他はもっと簡単な書き方してるだろ？

**デフォルトの名無しさん** · 2017/07/25(火) 22:27:51.60

>>724
http://qiita.com/kazusa-qooq/items/23926befcb87c0c7b26f
によると
req,res,nextの3引数を取る関数を作ればいいみたいね。
偶然にもクロージャーを使うというのは正解だけど
nextを省略してるってことは他のミドルウエアを後から追加したら
動かなくなる

こういうの見てるとtypescript使うべきって思う。
型でapp.useに渡すクロージャーを制約できるからこういう失敗がない。

**デフォルトの名無しさん** · 2017/07/25(火) 22:30:30.22

>>719
GCされてね？

**デフォルトの名無しさん** · 2017/07/26(水) 15:41:26.54

722です
一応、最小限っぽいコードを書いてみました。
http://www.dotup.org/uploda/www.dotup.org1319642.zip.html
users.jsからdbaccessを利用していますが、ここをtags.js, articles.jsと増やしていきたいって考えています。

>>724
本家のサンプルも利用者のblog記事なども一通り見たのですが、
見つかるは全部関数なので、そもそもクラスでの利用を想定していないのだろうと当たりを付けて
影響なさそうなクロージャにしてしまいました

>>725
ミドルウェアの追加は想定していない、クライアントコードなので特に支障はないと判断してます
本音を言うと、ただ書き忘れただけなのですけど。

**デフォルトの名無しさん** · 2017/07/26(水) 16:04:27.16

ちなみに、なんでクラスで書こうと思ったのかと言えば
クロージャとクラスのインスタンスが内部的には等価だと思っていたからです

**デフォルトの名無しさん** · 2017/07/26(水) 16:54:58.69

codepenとか使うかgithubに上げるかして欲しいわ。
正直zipでってなんかイャ

**デフォルトの名無しさん** · 2017/07/26(水) 16:56:23.68

>>728
将来の自分のためにも流儀は合わせておくべき。
コード量の削減に影響するとも思えない。

**デフォルトの名無しさん** · 2017/07/26(水) 21:17:16.61

>>728
thisが違うことから等価じゃないことが証明されてるでしょ？
じゃあクラスで書こうと思った理由は消滅してるよね？
ならクラスで書くのをやめるべきだよね？

**デフォルトの名無しさん** · 2017/08/18(金) 21:49:38.61

useの第2引数に何が許されてるのかドキュメント読みなさい

**デフォルトの名無しさん** · 2017/08/27(日) 14:46:16.26

forkの経緯を眺めてたけどこれio.jsの時と違って結構めんどくさいな
これまでのNodeは人治主義のOSSだったってことか

**デフォルトの名無しさん** · 2017/08/27(日) 15:42:03.26

シングルスレッドだから遅くならないって言うけど
マルチスレッド言語で動的にスケールすればいいでしょ？

**デフォルトの名無しさん** · 2017/08/27(日) 15:44:19.45

Node.js Foundationに対し不安を持つグループによるNode.jsのフォークプロジェクト「Ayo.js」誕生
https://mag.osdn.jp/17/08/25/163000

**デフォルトの名無しさん** · 2017/08/27(日) 15:53:01.24

>>734
だよな

**デフォルトの名無しさん** · 2017/08/27(日) 15:53:18.14

>>735
matakayo

**デフォルトの名無しさん** · 2017/08/27(日) 16:05:49.89

シングルスレッドだから遅くならないなんて言っている人なんているかねぇ？
C10Kの話ならかなりニュアンスが違う。

**デフォルトの名無しさん** · 2017/08/27(日) 16:12:18.21

優秀な一名をこき使うから速いんだな。
ほんの少しでも空時間があったら仕事をぶっこむ。
人間なら死ぬわ。

**デフォルトの名無しさん** · 2017/08/27(日) 16:17:42.17

>>738
メモリ使用量が増えないってnodeのメリットじゃないの？
そんなのスケールアウトで十分だと思うんだが

**デフォルトの名無しさん** · 2017/08/27(日) 16:22:23.64

> メモリ使用量が増えないってnodeのメリットじゃないの？
だれがメモリ使用量が増えないというメリットが有ると
いったんだ？お前の脳内か？

**デフォルトの名無しさん** · 2017/08/27(日) 17:35:42.54

nodeが良かったのはは非同期apiにより
プロセスあたりのリクエスト処理数を高めたからでしょう？
マルチプロセスにすればその分リクエスト処理数もある程度スケールしてくれる。ただしdbアクセスは考慮しないものとする

**デフォルトの名無しさん** · 2017/08/27(日) 18:30:42.93

mongoDBとかNoSQLとはなんだったのか

**デフォルトの名無しさん** · 2017/08/27(日) 18:57:54.53

>>743
nodeとは全く別もので、ただのデータベース

**デフォルトの名無しさん** · 2017/08/28(月) 11:26:19.65

Nodeが普及したのは良いサイバーサイドJS環境だったから

**デフォルトの名無しさん** · 2017/08/29(火) 09:43:28.14

let dict = {}
で辞書のように使おうとしたんだけど、
dict['constructor']ではまった
アレイにkvペア入れて頑張るしか無いの?
16万項目あるので線形検索は躊躇う

**デフォルトの名無しさん** · 2017/08/29(火) 10:19:27.35

Mapを使うとかlet dict = Object.create(null)とか

**デフォルトの名無しさん** · 2017/08/29(火) 11:53:07.27

>>746
16万項目のデータをメモリ内に置くのか。
もっといい方法無いかな。realmとか使えればいいんだけど。

**デフォルトの名無しさん** · 2017/08/29(火) 11:59:45.48

Object.createで上手くいった
try catchで検出してエラーになるのを、別管理と考えてたけど、すっきりした
さんきゅ

**デフォルトの名無しさん** · 2017/08/29(火) 12:07:49.40

>>748
db構築に使うフォーマット変換ツールなので、適切な時間で終了する事が要件で
利用リソース量はあまり気にしない

**デフォルトの名無しさん** · 2017/09/03(日) 12:30:07.14

eslintとそれにぶら下がるプラグイン本当互換性がない
ツール入れる所でトラブらないといけないとかだるいわ
これだからJavaScriptなんて書きたくないんだよ

**デフォルトの名無しさん** · 2017/09/03(日) 12:34:43.60

eslintのプラグイン何を使おうとしてるの？
使わなければいいじゃない

**デフォルトの名無しさん** · 2017/09/03(日) 12:59:47.72

airbnb辺りのプリセット使えばええやん

**デフォルトの名無しさん** · 2017/09/03(日) 20:32:32.58

そのairbnb関連のjsx-a11yとかな
https://github.com/evcohen/eslint-plugin-jsx-a11y/issues/283

**デフォルトの名無しさん** · 2017/09/04(月) 11:57:48.72

>>742
そういうのもNginxやApacheがある程度やってくれるようになってるからね。
後ろは好きな言語をそのまま使えばいい。PHP-FcgidとかuWSGIとかRackとかServletとか。

**デフォルトの名無しさん** · 2017/09/04(月) 18:58:52.14

>>755
非同期apiはphp処理系では無理じゃない？phpはインスタンスの生存時間がリクエストを受けてからレスポンスを返すまでの固定だよね。

どうやってイベントループ回すの？

**デフォルトの名無しさん** · 2017/09/04(月) 20:39:48.99

>>756
フレームワークによってはイベントループで生存期間が無限のものもあったはず。
前の会社で、そういうWebSocketフレームワーク使おうとしてたよ。

…そんな用途全く想定してない普通のPHP用のオレオレライブラリ組み合わせて
メモリリーク起こしてたけど（藁

**デフォルトの名無しさん** · 2017/09/05(火) 08:00:30.55

>>757
メモリリーク起こすなら使えないな。
phpってインスタンスの生存時間短い前提だから、
メモリリークってさほど気にしなくて良い言語なのかも。
素直にjsでいい気がするけどね。今の時代。
yahooで勤務してる知り合いも今はjsでサーバサイドを書いてるってさ。

**デフォルトの名無しさん** · 2017/09/05(火) 14:51:11.75

もともとCGIはリクエスト毎にプロセス作ってサービスしてた
なので、一つのリクエストが終了するとperlやphpのプロセスも終了するので、オブジェクトを解放(リファレンス外す)しないCGIが多くある

ところが、これじゃおせーよと言うことで、終了させないで無理やりに複数リクエストを処理させる仕組みをでっち上げた
これがPHP-FcgidとかuWSGI

リークしまくりのサービスが出来上がり

三菱とかやりそうだろ

**デフォルトの名無しさん** · 2017/09/05(火) 15:05:46.14

だから一定数のリクエストを処理したらプロセス再起動する
三菱でも大丈夫

**デフォルトの名無しさん** · 2017/09/05(火) 15:06:06.76

メモリだけじゃなくて
CPUもファイルI/Oも簡単に食い潰せるからな

**デフォルトの名無しさん** · 2017/09/05(火) 16:00:05.67

>>760
なるほどね。大雑把な作りだ。
大昔Dephiの案件をやった時に、PLが
ひとかたまりのEXEを画面ごとにバラバラのEXEにして
切り替えるたびに終了させる仕組みを作り出して、メモリリークを
極力抑える仕様にしてたの思い出した(データはDBにおいてる)

**デフォルトの名無しさん** · 2017/09/05(火) 17:07:49.21

>>760
三菱は自動再起動なんて技術がないから、連絡受けて手動で再起動してた

**デフォルトの名無しさん** · 2017/09/06(水) 21:18:48.34

何故、三菱が引き合いに出されるのだ?
なんかやらかしたんかい。

**デフォルトの名無しさん** · 2017/09/06(水) 21:34:30.85

Librahackで検索

**デフォルトの名無しさん** · 2017/09/06(水) 22:59:23.06

三菱電機インフォメーションシステムズ (MDIS) 製のソフトウェアは、
1時間に400以上リクエストを送られると他のリクエストの処理が不可能になる不具合を含んでいた

これか?
9秒に1回以上で破たんするなんてどんな実装か興味津々

**デフォルトの名無しさん** · 2017/09/06(水) 23:25:37.77

これを読むとイメージがわかる
http://takagi-hiromitsu.jp/diary/20130316.html
http://el.jibun.atmarkit.co.jp/pressenter/2012/09/1-0f4e.html (事件をモデルにしたフィクション)

**デフォルトの名無しさん** · 2017/09/07(木) 03:05:39.43

そもそもDOMとのメモリリークとかまともに対応してきたJS界のエンジンが優秀過ぎるだけで
他のサーバサイド言語で環境を跨いた循環参照とか上手く処理できるエンジンは無いし、他のGC技術や調整も何年も遅れてる

**デフォルトの名無しさん** · 2017/09/07(木) 06:19:08.39

WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
普通にやったんじゃできないよね。

**デフォルトの名無しさん** · 2017/09/07(木) 07:18:46.25

応答しなければいい

**デフォルトの名無しさん** · 2017/09/07(木) 09:17:55.33

>>769
expressだって、グローバルスコープの変数にコネクション保持すれば、その参照切るまで残るぞ

**デフォルトの名無しさん** · 2017/09/07(木) 12:06:54.84

>>769
膨大な数のリクエスト処理するのになぜ閉じるのかが逆に理解できないんだけど
普通WebアプリやサービスのDBはつなぎっぱなしだとおもう

**デフォルトの名無しさん** · 2017/09/07(木) 12:43:46.04

Webのセッションが終わってるのにコネクションをセッションのために１０分間保持してたって事でしょ?
普通はコネクションは閉じないがWebのリクエスト毎に紐付けは開放でしょ。

**デフォルトの名無しさん** · 2017/09/07(木) 13:10:59.01

>>773
アプリサーバーとか作ったことある？

**デフォルトの名無しさん** · 2017/09/07(木) 14:19:14.16

>>773
その紐付けを解放しないのが三菱流

**デフォルトの名無しさん** · 2017/09/07(木) 19:20:21.66

>>774
ないズラ
そんなヤツ僅少だろ

**デフォルトの名無しさん** · 2017/09/07(木) 19:23:08.30

>>775
三菱に限らずSIerの技術力低下が半端ない

**デフォルトの名無しさん** · 2017/09/07(木) 22:32:27.03

自分達の底辺技術レベルが原因で、無実のエンジニアを罪人にして、ほっかむりしたのは三菱だけ

**デフォルトの名無しさん** · 2017/09/08(金) 00:15:56.20

ちなみにDBってopenとtransactionを分離している奴があるけど、これって何で？
例えばIndexedDBでもそうで、open後にtransactionを作ってアクセスしなければならない。
しかし普通に読み書きだけなら
DBWrite(DBname, objectStores, key, value)
みたいなAPIでクエリ毎にopen/close繰り返した方が使う側は楽だよね。

何らかの理由でopenが重いから分離しているのだろうけど、
普通に実装すればそんなに重いとも思えない。
（実際はopenは数秒かかる時もある程重いが）
これって何で？

ちなみに類似ケースはXHRで、通常は毎回XHRをnewするだろ。
indexedDB.openもそれに近くて、本来はオブジェクトを初期化するだけで終わるはず。

**デフォルトの名無しさん** · 2017/09/08(金) 00:27:44.82

>>769
> WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
> 普通にやったんじゃできないよね。

コネクションプールを使ったら普通にそうなりますが？

**デフォルトの名無しさん** · 2017/09/08(金) 00:28:57.91

>>779
DBをopenしてselectしてcloseするなら
トランザクションいらないでしょ？

**デフォルトの名無しさん** · 2017/09/08(金) 00:31:58.67

>>779
> 何らかの理由でopenが重いから分離しているのだろうけど、
> 普通に実装すればそんなに重いとも思えない。

ゆえにopenが重いから分離しているという
あなたの想像は間違いだって言うこと。

根拠のない想像を結論にしないようにしよう
検証の前にあるのは結論ではなく仮定という

トランザクションは複数の操作を一塊にするもので
openが軽いのとは関係ない話

**デフォルトの名無しさん** · 2017/09/08(金) 00:47:45.77

>>781
IndexedDBの場合はトランザクションは常に必要だ。
他の楽観的なトランザクション分離のDBについては知らん。

>>782
では何故openとtransactionを分離するんだ？
最初からtransaction単位でopen/closeするAPIにしておけばいいだけの話だろ。
そこを分離して手動でやらせる理由が分からん。

**デフォルトの名無しさん** · 2017/09/08(金) 00:55:56.99

IndexedDB特有の話なら、IndexedDBの話だって書けよ

はい、トランザクションつかってませーん。ばいなら

http://qiita.com/butakoma/items/2c1c956b63fcf956a137#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%B9%E3%83%88%E3%82%A2%E4%BD%9C%E6%88%90

オブジェクトストア作成
オブジェクトストアは、RDBでいうテーブル。

var storeName = 'sampleStore';

var openReq = indexedDB.open(dbName, dbVersion);
// オブジェクトストアの作成・削除はDBの更新時しかできないので、バージョンを指定して更新

openReq.onupgradeneeded = function(event){
var db = event.target.result;
db.createObjectStore('storeName', {keyPath : 'id'})
}

**デフォルトの名無しさん** · 2017/09/08(金) 00:57:25.86

IndexedDB特有の話ならtransaction使わないと
readonlyなのかreadwriteなのか決められないからだろ

**デフォルトの名無しさん** · 2017/09/08(金) 01:14:01.64

>>779
DBへの接続(open)とトランザクションは別のレイヤーだからだよ
1つの接続で2つのトランザクションを実行したい場合どうすんの？

transactionを明示的に指定しない場合に
デフォルト設定で例えばステートメント単位でトランザクションになるような仕組みがDBにあればtransaction指定は必須でなくなる
一般的なRDBはそうなってると思うけど

**デフォルトの名無しさん** · 2017/09/08(金) 01:20:17.29

>>784-785
つかお前根本的に分かってないだろ。

IndexedDBはonupgradeneededの時は最初からトランザクションを張っている。
これはMDNからはとてもそうは読めないのだが、とにかくそう。

そしてAPIが
> DBWrite(DBname, objectStores, key, value)
> DBWrite
とかでいいのではないか？というのが俺の疑問なのだが。

何故かは知らんがDBには「繋ぎっぱなし」の文化はあるんだよ。>>772
IndexedDBのAPIからもそれは読みとれる。
> Web アプリが別のタブで開かれているときにバージョンを変更する
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB
毎回閉じる文化ならそもそもこれは要らない。

MDISはこの「繋ぎっぱなし」の文化でWeb側にも解放したらリソースが枯渇しただけだろ。
ただそもそもこの「繋ぎっぱなし」ってなんなのさ？
open/closeが軽いのなら毎回open/closeすればいいだけだし、
普通に実装すれば重いとも思えないし、ということなのだが。
（ただし実際にはIndexedDBでもopen/closeは重い）

**デフォルトの名無しさん** · 2017/09/08(金) 01:26:20.56

>>786
> transactionを明示的に指定しない場合に（以下略）
これについてはそれでいい。
APIコール1回＝1つのtransactionになるって事で。

> 1つの接続で2つのトランザクションを実行したい場合どうすんの？
これってどういうケース？
その2つのトランザクションをくっつけて1つのトランザクションにしておけばいいだけの話では？
並列性を限界まで出したくて、例えばライト/リードでトランザクションを分けておきたいとかか？

**デフォルトの名無しさん** · 2017/09/08(金) 03:16:51.74

>>788
1回の接続で複数トランザクションを実行したいケースってあんまりないのかな
例えば２つのトランザクションのうち後者が失敗しても前者をロールバックしたくない時とか考えてみたら？

トランザクションのたびに再接続するので良いケースもありうるけどそうじゃないケースもありうるよね
だから一般的にはトランザクション境界と接続の開閉を一つにしたAPIってのはいい設計じゃないと思う

>>787
繋ぎっぱなしの文化なんかなくて、ただの開放漏れのバグだよ
openしたらcloseするのが必須

**デフォルトの名無しさん** · 2017/09/08(金) 08:36:52.78

>>780
コネクションプーリングはコネクションを使いまわす仕組みだからDBには繋がったままだけどWebのセッションからはリクエストの度に切り離される。
とっくに終わってるセッションがコネクションを独占するようなアホな作りはどうやったらできるのかって事。

**デフォルトの名無しさん** · 2017/09/08(金) 08:40:11.92

>>787
繋っぱなしってコネクションプーリングのことでしょ。アプリから見ると毎回、open/closeしてるように見える。